(upbeat synth music) (audience clapping) - Thanks John, appreciate that.
Wow, hi, good morning.
Thank you John, that was really nice, a very generous introduction.
If you read between the lines what he was saying is that we're both very old. Here, look, look, remember that, that's 2005. - [John] Oh wow.
- Bondi Beach.
- [John] It is.
- Yeah, I think we've done all right since then (chuckling). We had this a bit yesterday, do I have to stand over here? I think that's what the speakers yesterday found out. Yeah all right, we're gonna be fine.
Yeah, that was a long time ago.
God, it's great to see a few hands come up when people were asked about remembering Hotwired. We had been doing this for quite a long time. This was the first website that I had the privilege to work on.
I got a job at Wired magazine in 1994 and if you do the math, that's 25 years ago now. That was a long time ago.
We didn't have much to work with, but we were very proud of the work that we did. The stuff I wanna talk about today is really a question that I have had, even since those days but increasingly important now in my new job that John alluded to, as a design partner at a venture capital firm. And the question that I wanna really get into, is this. Why do some products succeed, when others fail? I mean it's a super obvious question for all of us, right? Like it's what we do, is to try to figure out how to make products succeed and how to try to keep them from failing.
You know, when I ask people, especially now and the people that I work with in the investment community and things like that, when I ask them this question, I get a bunch of different responses.
Sometimes, people will say, the reason that the product succeeds and others fails, is just distribution, that's all it is. Coke and Pepsi are basically kind of the same thing, it's just that Coke is in more places, so it sells more. And you see this in our industry a little bit in what we call growth hacking, or growth marketing, things like that.
It is really just about getting people to the product and then things will work.
I don't quite buy that, I don't quite buy that. Other people, more sort of technologically-minded people, might just say, it's innovation, that's why some products succeed and others fail. It is because the relentless progress of technology, and miniaturisation and Moore's law that allows us to create these magical things. Technology is what drives product success.
I'm not sure that's true either.
I think if you, if we kind of polled this room, we'd get some flavour of this, probably.
I don't know, maybe that's my background in what we've always called user experience. But it is that products succeed when they satisfy some unmet need.
Now we can go out in the world and we can identify, where are people struggling? Where is there some need that they have that has not been met? And we can use research practises, and things like that and get a really good sense of okay, here is what people are struggling with, let's find a product, let's find a solution that meets those needs, and then products succeed. And the reality is that it is some combination of all those things. And any truth in the world today, is nuanced and a blend of all sorts of different factors going in. But it has been something that I have been focused on for a long time. How can we make things succeed and try to avoid failure (sighing)? One of the things that I have come to believe over all of this time, these decades that we've been doing this, it's that there's a truth that no product succeeds, no product has been successful when built by a single individual.
I mean it's exceedingly rare and there's a crazy exception. Maybe somebody like writes an app that goes viral in the app store, but products that really succeed, that have longevity, they are always built by a group of people that are collaborating together.
That it is teams that are behind successful products. And the qualities of those teams are something I'm super interested in now.
So, as I said before, I have this kinda new job as a partner at a VC firm, which is kinda a weird position for a designer to be in. But we have this hypothesis that the application of good design practises, user experience and research, and things like that, applied to a company at its very early stage, can reduce the risk of that company failing. And the only thing we have, the firm that I work for, only invests in the earliest companies.
Usually with just a couple people, maybe three of four. But they have an idea, maybe a little bit o' code and that's about it.
And the only thing we have to go on then, are the people there.
The idea has to be something we believe in. The market has to sort of, we have to be able to imagine that it exists, but ultimately it's the people.
And so what is it about these teams, and what could we figure out about teams and the way that we work together with one another to maximise success and reduce the risk? That's what I wanna talk about a little bit today. We have a lot of things that we can look at when we look at teams.
We can look at the backgrounds of the people, the credentials they have from the schools they went to or their previous success.
We can try to gauge how smart they are or how well they work together, things like that. But one of the things we've been really focusing on lately, one of the sort of, almost like this silver bullet, in today's world of technology, and the way we make products and who they're for and incredibly diverse audiences that we have, the one thing that we have been looking for is emotional intelligence.
Which is surprising that in a world of technology emotional intelligence is the thing that we find, that's almost a silver bullet, in making teams work together to make more successful products.
And what we're finding out is that frankly, EQ, is more important that IQ in the quality of the teams. And that's what I wanna focus on today.
How can we get better at this? How can we become, as a group of people working together, more emotionally intelligent to make better products? So let's dig into that.
And I wanna start with a little bit of, almost like a visualisation.
I want you to imagine this scene.
That you're in a canoe or a kayak and you're paddling through a still water morning, the sun is just coming up, it's very quiet. Then all of a sudden there's sort of jolt to the boat, and it flips over, and you're in the water, and you come up and you're gasping for breath, and you look around and what do you see, but a bunch of teenagers have kind of snuck up behind you, and grabbed the boat, and flipped it over, and they're pointing and they're laughing.
How would you feel in this situation? What is the name of the emotion that you might be feeling? Let me pick on you here in the front, sorry. - [Female Audience Member] Pissed off.
What's that? - [Female Audience Member] Pissed off.
- Pissed off! Good (chuckling), it's good to be in Australia. It's so different than (laughing), (audience laughing) it's so different than England (laughing).
Very good, anybody else? - [Male Audience Member] Humiliated.
- Humiliated, oh, oh, that's a good one too. Any other, anything else? - [Audience Member] Surprised.
- Surprised, great.
Anger.
- [Audience Member] Wet.
- Wet, that's good.
Some people might feel embarrassed or afraid, that's another big one.
Now imagine this scene one more time.
Let's kinda rewind.
It's the same thing, quiet, sun is rising, you're in the boat, and there's a thud, and you flip over, and you come up and gasping for air.
And, we are moving on our own, aren't we? And you come up, and you're gasping for air, and you turn around and you see a piece of driftwood that your boat has run into.
(clicking) Let's try that. Can we come back, let's see.
Is it coming back? A piece of driftwood that your boat (chuckling) has run into.
What would the emotion be here? Would you feel anger, would you be pissed off at the piece of driftwood? No, probably not.
You might feel frustrated, you might feel embarrassed, it might turn into shame or something like, ah, I wish I was better at this. I love this hobby but I keep screwing up.
Why do I keep screwing up? These are all a set of emotions that we might feel. The trick is here, the key to all of this is that in each one of these situations, whether it's the teenagers or it's the piece of driftwood, we can choose to have the same emotional response. We can make it a choice, and we can practise making that choice and get better at it over time.
There will be a trigger, in this case, the boat flipping 'em in the water.
There'll be an automatic physical response, right? Ah, I gotta breath.
Your body will just do that, your brain will get you there. The same response as like getting your hand out of the fire. But then the emotions that come after that, that is something you get to choose and it's something that is a skill we can learn over time. That skill has a name, and it's call equanimity.
Equanimity's defined as a state of emotional stability especially in a difficult situation.
Emotional stability in a state, especially in a difficult situation.
Another term that we use for that is grace under pressure. How do I respond when something happens that triggers huge emotions? And what I wanna talk about today is how do we cultivate that? Not only in our ourselves, but in the teams in which we work, the people with whom we collaborate.
How we can we grow our equanimity in times of stress both individually and as teams? So, let me tell you a story about it.
This is something that happened quite a while ago now, while I was still working as the founder of Typekit. And it was early one morning before I normally wake up. It was dark out, it was December.
And I woke up and I heard this strange sound. And I followed the sound, I got out of bed, followed the sound down to the bathroom.
And I looked in the bathroom and I found this. (audience laughing) So the good news is, I know who this is.
(audience laughing) And the bad news is he was on his third roll of paper, just wedging 'em down in there, really working hard at it. Truly diligent (laughing).
So, hmm equanimity, here's a good example.
As a parent, practising , okay, I have a trigger here and I'm going to choose which emotion I practise. So I did, we sort of figured this out.
We got the problem sorted out.
It was early in the morning.
Brought him downstairs to have breakfast and while he was having breakfast, I did what I normally did in the morning which was log on to Slack, which is how we've ran our company, and how many of you probably spend your day, as well. And as it turns out, there was a lot of activity at 6:30 in the morning already, which is unusual.
There were code deploys already happening, a lot of people chatting and lots of things going on. I kinda did the scroll back and looked at what was happening and there were problems.
Things were not going well for Typekit that morning. A lot of what was happening was directing me towards the system we have for monitoring, or monitoring all the various systems that we have, and in particular, there was a chart that everybody was talking about that looked like this. Now I don't know how many of you are experts in data visualisation (audience laughing) but this is a chart of something going pretty well and then (hands clapping) all of a sudden going really poorly.
And to explain how this works, let me explain a little bit about just what was going on with Typekit.
So Typekit, as John mentioned, fonts on the web. The kind of the key innovation here was that the fonts were hosted and that you just pull up a job script on your page and then things work.
So that divorcing the technology of fonts from the creativity of fonts is kind of the goal. Ultimately, you would go around and you pick whatever fonts you want.
And then crucially, you would do a little bit of configuration to get 'em onto your website.
And then hit this button, Publish.
Hit the button and the fonts magically show up on your website. Magic.
And in the background, here's what's going on. So push the Publish button, we take fonts formatted for the web, some JavaScript and CSS, and some configuration from the database, merge that all together and put it into something that we metaphorically would call a kit.
We would take that kit, that bundle of code, and we would push it out into a thing called a content distribution network, a CDN. And what a CDN is, that it takes that kit and it puts it on one of its servers and then (whooshing) broadcasts it out to the rest of the world.
Because we all know how important performance is in web design.
And the speed of light is too slow for most performance. If you want to have a page load very quickly you want the assets on the page to be very near the people. We shouldn't be loading them from Silicon Valley, we should be loading them from Melbourne when we're looking at pages here.
So (whooshing), they get broadcast out all over the world. This is a chart of then, all of the fonts, all of the kits rather, that have been queued up, ready to be pushed out into the world, but haven't yet gone. So that means people are going to that interface and they're clicking Publish.
We're making the kit, but it's not going anywhere. They're getting more and more of 'em on our servers and not on that CDN.
And so what happens then is people go back to the interface and they push Publish again and they reload their page, it doesn't work. They push Publish again, and they reload the page, and all of these people are doing it, and more, and more, and more, and more, and it's getting really backed up and nothing's working. So we get into the office and the engineers have already sort of kind of uncovered what is going on.
Not why the queue is getting so big, but why the problem started in the first place. And that is because of one of our partners. There's a startup called about.me that we had partnered with, and we provide the fonts for them.
They make this service that allows people to make their own personal webpages, single-page website, and very beautiful webpages with all of the fonts coming from Typekit.
And it turns out they're giving us a hundred times more traffic than they ever have before.
And that's because they had been in sort of, kind of like this early alpha release.
But as it turns out, this morning, they launched. So I call the CEO and I'm like, hey, that's him there, Tony.
And I call the CEO and I'm like, hey, congratulations on the launch.
Thanks for letting us know (chuckling).
Things are a little slow on our end.
He's like, yeah, yeah, we've noticed something wrong with fonts on it. Yeah, yeah, yeah, no problem, we've got this sorted out. We're gonna figure it out, absolutely.
He's like, great because like I know we just launched, but like we have big news coming on Monday that we have actually also been acquired and that AOL is gonna buy us and we're gonna be, there's gonna be news in the New York Times and the Wall Street Journal and it's just gonna be huge.
I'm like, that's great, congratulations! (audience laughing) And (chuckling) this is the part where I tell you just how small Silicon Valley is. Because not only is Tony the CEO of about.me, but he's also an investor for the firm that funded Typekit (chuckling). And he is actually also on my board, that's how we started the partnership.
So in kind of a way, he is my boss, a little bit. And he's saying so (fingers snapping), we're good for Monday? And I'm like, absolutely we're good for Monday. And while he's saying that, I'm thinking (mumbling), (audience laughing) good for Monday.
He's like, great, 'cause you know, we want this to really go well. And I'm like, absolutely it's gonna, (audience laughing) gonna be very.
So it's Friday and that's Monday.
And it's Friday and it's like the weekend before Christmas which where we come from, is the middle of winter, and half of the team was gonna go snowboarding this weekend.
And this is where we started to talk about some of the values that we have as a team.
(audience chuckling) About (chuckling), we work for a startup and part of the pitch is look, there's a lotta risk when you work for a startup, but there's a tremendous amount o' opportunity, as well. The distance between you and the problems you're solving for users, is never smaller. There's not like, you know, the six month wait for your code to be deployed as it goes through legal and all that stuff.
You think of an idea, we get it out, it goes really fast. But boy that comes with a lot of responsibility and that means we hold the service up, as well. And we did, we collectively decided this is one of those moments.
We have to do it this weekend! So we had these three days to fix this problem. And this is kind of the first application of this concept of equanimity. And one of the key things that I found, especially in the life of our little startup, is that we could take moments of big anxiety and apply structure to them as a way to manage those emotions.
And so here's an example of that.
We took the three days and decided that on the first day we would do everything we could to identify what the problem was.
On the second day, we would develop a solution and build that solution and then on the third day, we would integrate that solution into our existing code base and launch it.
Already now, we're saying, it's not some huge, unimaginable problem, but there are three steps that we're gonna take. And today, we're just gonna focus on that first step. And so we got to work and the first thing we did was sequester the team. Doing web design, building web products is not rocket science, but there's a lot we can learn from rocket science and the tremendous amount of amazing work that happens under intense stress and pressure, especially in situations like this, where every single person knows exactly what their role is, what they should be doing, who they should talk to, who they should not talk to, what they should say and what they shouldn't say.
Really interesting to look at those structures. And this a little bit of what we did.
We isolated the team that was responsible for developing everything, for solving the problem, and kept that team away from all of us who would triage the damage that was out there with partners, and investors, and customers and things like that.
We identified one person on the team, on the developer team, that would come and go and be the liaison.
You tell us when there's something.
We won't come and keep bothering you to find out what's going on.
And it worked really well, especially when they knew that all they had to do was focus on the problem.
They didn't have to worry about customers, or vendors, or partners or any of that kind of stuff.
We removed the business decisions from solving the tech problems and allowed them to do what they do the best. And then of course we provided as much moral support as we possibly can.
This is a very startup refrigerator, nothing but craft brew and soy milk (laughing). (audience laughing) But here's what we're doing, we're trying to create a sense of equanimity, grace under pressure.
We are setting up the conditions for success by applying structure to manage anxiety with the goal ultimately, of developing such equanimity so that they can perform their best in this moment that sort of feels like the company is hinging on it. So here's our evaluation of identifying the problem. We are making kits just fine.
Like the system has plenty of headroom to be able to push that Publish button as much as you possibly want.
And the bandwidth in between us and our partner who does the CDN, is fine.
There's plenty of connection and everything's working out. It is that origin server, that is the name of the server that takes the kits in and distributes them that is just not working and it's not something that we can control, it is something that our partner has.
But they're just kinda bouncing off, it's not working at all.
We don't know why.
So we dug into that idea of this origin server and realised this is the first place where we caught a break. Because we had a plan, a product plan, that we had already developed, to do our own origin server.
Because we wanted to add some additional features. We wanted to do dynamic subsets of fonts and things like that, that weren't supported by them, but they had an API, so we could be able to do that. And when we looked at that plan, we realised we (hands clapping) can do this, we can replace the origin server and make it much higher-performance than the one that's been given to us by our partner. And according to our plan, it'll only take about 16 weeks, (audience laughing) so let's do that on Saturday instead (laughing). We talk a lot (chuckling) in the startup world about minimum, viable product (chuckling).
How simple can we make something that accurately represents what we need do without a lot of investment so we can test to see if it works? Wow, what a good example of that.
And they made the absolute stripped-down, feature-free, high-performance version of that product, in a day, ran that overnight on Sunday and watched the kits gradually go down, faster and faster until we were there and they turned out that that was the solution that was gonna do it.
Monday morning, they announced the acquisition to AOL. Fonts were loading on the page and a surge of traffic that was 10 times or 20 times bigger than we had ever seen before, became the new normal for us. And so, we got there.
And this is from the head of our architecture of our infrastructure, Paul, who later went on to do the same thing over at Slack. And you can see a sense of those values that we talked about.
Those startup values of both opportunity and responsibility come together.
It's great.
So what did we learn from all of this? There's a few things.
One of which, I really wanna dig into, today. One of the most important things that we learned is that everything we build on the web is connected to one another.
And everything breaks all the time.
That you can be doing a migration from your rack space data centre over to AWS and a hurricane can hit Virginia right in the middle, at a crucial point, and that's gonna happen sometimes. Everything breaks and that's what we should be designing for. We should design our teams for that, we should design or products for that, our infrastructure, everything.
Because everything will break at some point and you can't build anything that's not connected. The other thing we learned is that everything is user experience.
Oh my gosh, this feels like a couple of decades worth of experience that I've had, trying to get the world to understand that everything is user experience.
It's not just the cool interface that you made on the screen that people interact with, but it is the performance of the infrastructure that you have, has just as much impact on user experience. It is the terms of the partnership that you have that affects user experience.
And that the people involved in negotiating those terms or developing that infrastructure, are part of a user experience team, ultimately. Everything is user experience.
But the thing I wanna talk about more today is that teams thrive when they have this sense of equanimity.
The sense that no matter what happens, we are capable, that we are a team and we could do that.
Now, a few of you were here yesterday.
And yesterday, was a focus on designing leadership. And this came up a couple of times.
And I wanna talk about it again here.
This is a project that Google did probably about five years ago now, called Project Aristotle. And this project was an attempt by Google to understand why some projects succeed and other projects fail.
That same question that I've been wondering about. But they did it in a very Google fashion which is they collected a tremendous amount of data on the hundreds of projects that had happened in the history of the company, and tried to look at every asset that went into that to look for some correlation in the data for project success.
Was it the IQs of the team members, or their school that they went to, or the number of code deploys before a launch, or what was it, the size of the team? They could find no correlation across all of their projects that they had done, until they did surveys with the teams to find a more qualitative answer to what had happened with a project that succeeded.
And the one thing that they found that went across all of those projects that succeeded at Google, was a sense of psychological safety among the individuals on the team.
That was the key.
That's the thing that in this company that is renowned for its computer science and its technical ability, psychological safety of the team members.
And what they meant by that, there was this article about this in the New York Times, and here's a quote from it, that the team members had "a sense of confidence "that the rest of the team would not embarrass, reject "or punish them for speaking up." That in the context of the meeting with the whole team that you could say anything, no matter how creative or outlandish, you could say anything and your team members are not gonna punish you. That your status will not reduce in the group by being creative, by saying something risky, by being a little vulnerable.
This is incredible, that that would be the thing that helped teams succeed.
It doesn't just happen in technology.
I found this great interview, I think it was in Vanity Fair, with Steven Soderbergh the film director.
He's done Ocean's Eleven and Erin Brockovich, films like that.
And he was talking about what has made his process successful, something very similar.
He said, "Some people believe tension "is a good creative tool.
"I am not one of those people." He says instead, he likes to keep the environment on his set relaxed but focused, relaxed but focused.
And how does he do that? With his actors, he says, I'm not trying to control them. I'm looking to amplify whatever it is I find compelling about them. Very, very different than the way so many companies function.
We don't learn to work this way when we go to school. We don't learn to work this way when we get our first jobs. We tend to go work for companies that base their process and their culture on the way companies always have.
Which, frankly, goes back to this, to where work looked like this.
Where in the back, you have physical resources and in the front, you have human resources. And you put those things together and you have them be more productive.
And that is this dude's job, the manager! And he's got his clipboard and his, you probably can't see it, but he's got a little stopwatch, and he is making sure that the human resources are productive and that they are not causing defects.
And if they do cause defects, well, they are probably punished.
This is the way so much work happens.
Does this feel like a relaxed and focused environment, with a sense of psychological safety? I don't know, what do you think, does this guy? (audience laughing and talking) Here, let me just show you.
Is that a sense of psychological safety (chuckling)? I don't think so.
This is where a lot of our work has come from but this is not what we're trying to create. What we're trying to create is a culture of creativity, where we can be our most creative selves without any fear of losing status with the group. And when I say creative environment, I don't mean like fancy offices with free lunch and pods for napping.
I mean a place where people have a sense of shared values with one another.
Where they feel safe, a sense of camaraderie, a sense of trust.
This is what we attempt to create.
So I wanna dig into this, this is what I wanna do. So let's get a little more practical and talk about how we can do this.
Now, before this current job that I have, I worked at Adobe for a number years and for as creative a place as Adobe may seem, it is still a Fortune 500 company.
And if I were to describe the culture there I would say the term that comes to mind is probably Microsoft Outlook (laughing).
The company has a meeting culture that is tremendous. Like in a typical 40-hour week, my calendar would somehow have 60 hours of overlapping things on it, where I was expected to be. And they would just show up there, they would just pop up there automatically. I don't know how that happened.
But that was what it was like.
And it was in stark contrast to the way in which we collaborated when I was at Typekit and we got to define how to work.
So I thought I would juxtapose those and talk about the meetings we had at Typekit as a way of talking about the culture that I tried to create.
And so I wanna talk about meetings.
This is generally how I felt about meetings as a practical alternative to work.
But I wanna walk through some of the ones that we did at Typekit as a way to talk about how we did collaborate with one another to create that environment.
So, let me talk about the first one and that is the standup.
Wow, it feels like lots of people have stand-ups now. This was again, like 10 years ago, not quite as common. And I don't really wanna talk about the process of agile and things like that.
It was not really about that, it was much more about a way of starting our day. And this is where I took some inspiration.
How many of you remember the show Hill Street Blues? Anybody here, oh wow, cool, a few people.
This is a cop show in the 80s I think it was, maybe the late 70s even, and it was set in New York and it was kinda this drama about what it was like to be a cop in New York at the time. But every single episode of the show started with the sergeant, at the beginning of the shift, going through a rundown of what was happening that day. Ah, there's some pickpockets over at the subway station and ah, we're still looking for this drug dealer in the Upper West Side, you know, stuff like that. He'd go through all of that and he's like, all right (hand slapping) great. That's what we got today.
Everybody would get up and he'd be like, oh, oh, hold on, hey, be careful out there. He would say that every single time.
And it was just sort of like this warmth that would come from this really gruff old sergeant and it was really quite nice.
But they started their day together and they did a very brief rundown of what was happening, couple questions here and there, but then, all right great, that's it, all right, go get to work, that's good and be careful while you do it. And that was what we were trying to achieve. Not some kind of like agile process with Post-it Notes and everything else that works very well in many different circumstances.
But instead, much more of a greeting, of a, look, we're gonna start together, and the day's here, and we have momentum and we're gonna go. So here's a couple o' things that worked for us. We started the day, every day, at 10:05.
I don't know why that works, but when I started the meeting at 10, nobody got there until quarter after, so 10:05, everybody shows up on time.
Everybody in the company attended.
The sales people were there, and the support people, and the engineers and the designers.
Everybody was expected to be there, but very few people spoke.
It was a highly-scripted event, almost performed, in which one person, generally me, would conduct the meeting and then there were representatives from all the other groups of people in the company that would do their little readout and things like that.
There were no devices at all.
And here's a little tip, when you facilitate meetings, especially if you wanna create an environment where people don't feel shame or anything, which is to just wander around while you facilitate and if somebody's kinda getting into their phone, just stand behind them and talk for a little while. And everybody will look at you, 'cause you're talking and they will stop (chuckling). But the key here, the key to this, is no problem-solving, none.
Take it offline.
So somebody will say, yeah, I was having a little trouble with this system and somebody else will say, hey I think I know what's going on with that. And I would say, great, can you two talk afterwards? Always talk afterwards.
As soon as we start doing some problem-solving in our morning standup (clears throat), excuse me, it goes from 10 minutes to an hour and then nobody wants to be there.
Nobody wants to hear about those other people's problems, let's just get through all of that.
People ask me about tools all the time.
Did you use Trello or was Asana better than that? And I'll tell you what, for the first couple years, we used this email and (chuckling) I would perform the meeting, and somebody else would transcribe what was happening, and we would copy and paste, and copy and paste and just keep going like that, for a long time. There's all kinds of tools that work, but ultimately the tools are a reflection of the culture of your team and that's what we were focused on.
So we didn't need to get to that for a little while. You may be very different, but that's not really the point. The point is to stay focused on what's working for your team.
So let's talk about the second meeting and that is the product review.
I've worked at Google for a few years and Google back then, this is again, quite a while ago, 10 to 12 years ago, and back then, Google was notorious for these things called design review.
And you would go in to the design review and there'd be a whole group of engineers and it felt a little bit like this.
(audience laughing) You would have your beautiful idea of this clay pigeon that you had created.
You'd like, look at what I've done and the engineers would be like boom! Here's what I think of what you've done.
It was brutal, it was absolutely brutal! And so I wanted to change that when we started Typekit.
And so the first thing I did.
Oh by the way, this is Frank Lloyd Wright's, it is a room in his studio where his students would come and show their work and they would do the critique.
I don't know why Frank Lloyd Wright put a tree in the middle of the table, but he's the expert so it's gotta work somehow. But we called it product review.
I wanted to take the design part out of it, I didn't wanna call it critique and I wanted it to be about the product and not about the specific design.
And so we had all kinds of stuff that would come up there. It would be a new interface that somebody was working on, or maybe a database schema, or maybe the new deck for the sales team that they were gonna use, but we'd bring that together. This was an optional meeting for people to attend. It did not require the entire company.
But if you were there, you were working.
It was participation, was mandatory.
Roll up your sleeves, this is the time where we are together and we're gonna work and we're not gonna sit around endlessly discussing things, we're gonna make progress on this. The ground rules were that it was not a forum for expressing opinions.
And this is crucial, this is absolutely crucial. Let me give you an example.
I put something up on the screen, we're going to talk about this.
So bad feedback is, I don't like that blue. That's aggressive! What is it saying, what is the subtext there? I don't like that blue, I don't like what you've done, I'm better at what you do and I don't even do that, I'm smarter than you, I don't like that blue. Try this.
Let's turn it into an open question.
Why is that blue? There's still a lotta nuance here, body language and tone can make her like, (huffing) why is that blue versus oh, why is that blue? But at least we're opening up a discussion about the decisions that you have made and I wanna know more about the decision.
So even better is, is colour important here? What are we getting at here where is this solution coming from? Let's talk about the decisions you've made and help me understand why that is.
The other thing that was crucial is that at the beginning of each one of these sessions, we would lay down whether this was a convergent or a divergent meeting.
A conversation where things were opening up or coming together.
Let me dig into that just a tiny bit here.
A divergent meeting is essentially a brainstorm. I have this little germ of an idea.
We have this problem that we wanna solve.
How many ideas can we come up with that you can help me generate so that we can then explore all of those ideas and come back with a proposed solution? So this means that we are brainstorming.
That we have limitless possibility.
No idea's a bad idea.
This comes from improv, I don't know, you've probably seen some improv and maybe some of you have done this.
This is a very sort of team building activity, let's all go do improv training together.
This is the idea of yes, and, and that's crucial to good improvisation.
That is, imagine two of us on-stage and I say something like, wow, there was a lot of people on the bus today, and you say, not really.
(audience laughing) Thank you everybody, we're done.
Everything builds, yes, and.
Yes, there are a lot of people and that guy's coat is super weird, or whatever. And off we go, now we're building on something. This is a product review where I have a problem I'm trying to solve and I want as many ideas as I can possibly get. As opposed to convergence, we have done that.
We have collected a bunch of ideas, we did a bunch of research, we tried a bunch of solutions.
Let me walk you through all the ones that failed, until we got to the one that works.
Here's the one that works.
Can you help me evaluate the feasibility, can you help me acknowledge the technical constraints, or business constraints, behind it and can we drive towards consensus? Very, very different meeting.
And when these things get crossed, meetings just backfire, they explode.
So many times, oh my gosh, I find this where I am trying to get to convergence, I'm trying to get down to one idea that we are gonna collectively agree to pursue, and somebody wants to do a little more brainstorming. Ah, you know, I gotta a couple of other ideas here, have you thought of this? Always tends to be maybe the most senior person in the room who wants their idea to be heard.
Happens all the time and it's incredibly frustrating. Setting this up at the beginning as a set of ground rules, that this meeting is one or the other, is great. Now, how we get, when I said anybody can attend, this is something I focused on a lot, which is that when we have developers in the room, or even sales people in the room or anybody in the room who is not just working directly on the interface or the product, we get so much better feedback, but we need to help those people be able to participate, to get better at providing feedback.
And there's a few ways that we have done that. One, again, when we talk about silver bullets and how our teams do better product work is that by having people exposed to users, especially if those users are using the product, we get better design instincts, by anybody. When I have developers or sales people, customer support people watch user research happen, it develops in them a sense o' empathy for those people that erases a lot of the ego that used to go into developing in our products. Instead of, I think we should do this, we get a sense of remember when we watched that woman from Florida, who couldn't quite get in and let's solve this problem for her.
So getting everybody in the company to view user research, at least once a quarter. An hour a quarter is what we try to go for, for everybody to be able to have exposure to users. Another thing we did was have exposure to great work. We would have candidates for new foundries that were gonna go in the tech kit and we would show their work.
We would look at our customers who were using the product in the beautiful websites that they were building, we'd look at all sorts of good design and to help the entire team develop a better design vocabulary.
And then the last thing that I found, that really works, is the team itself and the makeup of the team. And that the more diversity that was on the team, the broader product insights we would have and it would make for better product development. When you have people of different ages or different socioeconomic backgrounds, or different cultural backgrounds or racial backgrounds, people that come from a variety of different places, can anticipate the needs of different groups of users and makes for a much better product.
What we're trying to achieve is a sense of candour. Truth that's wrapped in compassion.
I want to tell you the most honest thing I can about the work that you're doing, that I care about you as a person.
That's candour, that's what we're trying to achieve here. Ultimately, because we wanna develop in our team a sense of good taste.
And I don't mean that from a sort of, it's very easy to get, when you walk about good taste, start thinking about class and just like this way of judging other people. Eww, they don't have very good taste, oof, look what they're wearing.
No, that's not what I'm talking about at all. This is a sense of pride in the work that we're doing. That we are making something that is as good as anything else out there in the world, and we have good taste, that we know what we're doing here. And that's what we're trying to achieve.
And all of us, through the mechanism of product review, this is sort of a touchpoint.
All right, so another meeting.
Meeting number three, which is the bad meeting. The meeting you never wanna have happen which is the postmortem.
Something has gone terribly wrong, then we fixed it and now we wanna talk about how we never have that happen again.
The postmortem.
I put this image of a very industrial-looking scene here because so much of this comes from that era of quality management and trying to eliminate defects in production lines and things like that.
There's a lot we can learn from that, although our work is very different.
We deploy code, we make changes to a live server, a live system, all of the time.
Some of us, at startups, who multiple times said, hey, that those live systems can often be very fragile. The story I told earlier is a good example of that. Such that, when you push the button to deploy the code, sometimes very bad things happen.
Sometimes the service goes away.
But here's the thing to remember about that is that the person pushing the button assumes they're doing the right thing.
They know they're doing the right thing, they've done this a bunch of times, but this time, when they push the button, the wrong thing happened.
The circumstances were different.
Nobody pushes the button thinking, I'm gonna take the service down, unless they're some kind of sociopath or something. They push the button, thinking progress is happening, not, disaster is looming.
But, our instinct as humans, is to look for blame.
Who pushed the button, why is the service down? Find that person and get 'em in my office right now. Why did this happen? Why did you take the site down? We look for blame and that is such a part of human nature that there's a psychological term for it.
It's called the fundamental attribution error and that is where we make the mistake, as humans, of ascribing bad behaviour to somebody's attributes, their makeup, their constitution, rather than the circumstances in which they were performing, and we do it all of the time.
And I think it has something to do with the fact that, oh thank God it's not me. I can blame somebody else.
I'm not gonna get ostracised from the team, we can find somebody else.
This is an incredibly common phenomenon and there's ways through it.
And the ways through it, are again, ways of helping people perform with equanimity. So, I found a lot of inspiration from Sakichi Toyoda.
He is kind of considered the father of the industrial revolution, the rebuilding of Japan after World War II. And he focused a lot on industrial process. And he came up with this thing, probably many of you have heard before, which is the concept of simply asking why did the problem happen, but continuing to ask, why, five times, until you've drilled down to the root problem. Let me give you an example of this, in action. So, there's a story that is perhaps apocryphal, I am not sure, but it is a good story so we will pretend it's true of Jeff Bezos turning up at one of the Amazon distribution centres just to see how things were going, and the distribution centre was shut down, it was not working.
He was like, what is going on? And he gets his whiteboard and he writes, why, at the top. And the reason why is that an employee had injured their thumb on the assembly line, or on the packing line, and he wanted to know why that happened.
Why, because the employee's thumb got caught in the conveyor belt.
Well why did that happen? Well the employee was chasing their bag.
Why was he chasing his bag? Well he had put the bag on the conveyor belt and then the conveyor belt started up unexpectedly so he had to run after it.
Why did he do that? Well he was using it as a table.
Why was he using the conveyor belt as a table for his bag? Because there's no place to store personal belongings. So instead of firing that employee, why don't we get lockers? And this problem will never happen again and we can keep things going.
So look, let's apply that to what was going on with the Typekit situation. The kit publishing had stalled and how did we know that? Well why, because the queue was growing, that's because kits were not being delivered, we could see. Why was that? The origin server, it was not accepting kits. Why is that? Well the vendor's origin server, turns out, was designed for very high output, but not so high input. Why was that, what was the root cause? The input rate was not defined as a requirement a year ago. We had no idea that things would be this big and happen this quickly.
The root cause, by asking, why, five times. So let's talk about the last meeting, and that's kinda the anti-meeting, which is group chat. How many of you spend your day in Slack now? Yeah, lots of hands.
Oh good, not as many hands, things are changing a little bit.
It's interesting, even with Slack going public this year, that's really interesting information.
(audience laughing) The group chat phenomenon, I think, is something that really was really taking off when we started the company a bunch o' years ago. And it really fundamentally changed, I think, how we thought about our work.
Typekit was about 60% of us in San Francisco and then 40% of us cover around the world.
Sort of distributed, but we acted as if everybody was distributed, and I really appreciated that, especially from a leadership and communication perspective in that we had this communication tax that since not everybody was there all of the time, had to keep explaining things over and over again, to make sure everybody heard.
And it turns out that even the people who were there, benefited tremendously from that.
And one of the things I really liked about chat versus email, was the sense of communication compression. Email is based on a paradigm I think from desktop publishing of the 80s, that if you say I want a new email, it opens a document that looks like, essentially, a piece of paper with all this space where I type words, and words, and words, and words and words, because it looks like I should.
How many of you could get a four paragraph email from your boss and reply to it with this? (audience laughing) Maybe a couple of you, yeah, but yeah, maybe. But no, it's like he uses a lot of words I should give you a lot of words back and thank you for your note, and I appreciate the sentiment, and thank you for writing to me and here's my answer, no. So it takes a lot (chuckling).
Whereas when we are in chat I think a very typical conversation looks like this, where we are just working and it's back and forth. And it removes hierarchy, and any sense of power dynamics and we're just having this conversation.
And it's good, and it's fast, and it's a sense of momentum and I like that. The other thing I like about it, besides just compression in communication, is the sense of ambient accountability that one of the key things that I think Slack got right was the integrations.
That all of the systems that we have set up for doing our work, whether it is the ticketing system for support or the code repository and deploys with GitHub, or the way in which we track revenue with Salesforce, or whatever reason, got all of those things, the output of the activities that happen in there, go into the chatroom.
So everybody goes to the chatroom to see the output of their work and the output of everybody else's work, and you get this sense of ah, we're all doing stuff, there's a lot of momentum.
Oh, look what they're doing over there in support, that's amazing.
This all comes together and we get a sense of momentum for the whole team, that we're all doing our work and it's great. And we celebrate each other's work.
And of course we do that with the latest animated GIFs. And it feels a bit frivolous, I get that, or some kind of weird bit of culture that's emerging and things like that.
But I'll tell you what, you do a bunch of work and that work culminates in some of that, that happens in the chatroom and you go over to chat and it looks like this. And it looks like, hello, it looks like this and it feels really good.
I did some good work, that's awesome.
And if you do really good work, we saved the best for the amazing Chuck Norris, thumbs up.
Why is my, Chuck, where are you? I don't know, Chuck's supposed to give us a thumbs up, but oh, there he is, thank you.
(audience laughing) The best you can do.
But like I said, it might feel a little bit frivolous or something that just sort of happens, but I believe it's really just an emergent part of this same idea, this nucleus of emotional intelligence that comes to us as equanimity.
This is idea of we care about each other, we trust each other and I feel safe here.
We are probably taught that we should show appreciation for the people that we wanna have relationships with.
That we should go to somebody at work, look them in the eye, and say, I think you're doing a really good job. I really appreciate that you're on the team and I enjoy working with you, thank you.
Like that's great and we should all do that but then, I'll tell you what, it's emotionally expensive and it's hard to do.
And we do it sometimes, but not enough.
But I think this kind of stuff, like the little emoji reaction can be thought of as a sense of continuous micro-appreciation. I appreciate your work, hmm, good thing, you did a good thing, that's great, and that they build up over time.
And that it accrues into a sense of well-being with each other, and I think that's important.
All right, so let's do a little review and get into the really deep stuff here at the end. The sense of teams having equanimity and how we build it. We are striving for a sense of psychological safety for ourselves and for the people on our team. So we do that with clear expectations for communication. When do we speak to each other, when do we not? How do we speak to each other and what is the way to build that with one another? Like any good relationship, having conversations about the conversations, is the key to success there. Anybody that you have a relationship with, be able to say to them, I felt this when you said that. It's magic.
We can build empathy for our users and for each other through exposure to the people who use our products and diversity in the team, to create this sense of empathy.
Circumstances are much more important for us to focus on than the attributes of the people in those situations. Incredibly important that we focus on root causes rather than what we perceive as mistakes, and blame. And that continuous accountability and appreciation can lead to building up the team and having them feel connected to one another and appreciated.
But the thing I wanna end on is the sense of all of us being unified by a common purpose, common purpose.
And we talk a lot about goals for our projects, milestones for the team and things like that. We even talk about mission statements and things like that. Like I said, I worked at Google and we had this wonderful mission back then, a little different now at Google, but back then there was a notion of organising the worlds information and making it universally accessible, universally accessible.
That was motivating! And every day, we could connect what we did to that mission.
The work that I'm doing today connects to this because I'm helping get this information accessible to more people.
It was powerful.
This sense of purpose, though, goes even farther than goals, and milestones and mission statements. A sense of purpose is why does this company even exist? What are we trying to do that's building in the world, that's even bigger? So let me give you a sense of how I think about this. There is this concept in Japanese culture called ikigai, and I'm sure I'm not pronouncing that properly and I apologise.
But it is this sense of purpose that pervades Japanese culture.
And there's this study that happened, over many decades, with tens of thousands of people in which they periodically surveyed people and measured their ability to articulate how their work connected to a larger purpose. And what they found was direct correlation between a person's ability to articulate their purpose and the length of their life.
People lived longer when they had a strong sense of purpose. They didn't die as young.
They didn't have as many cardiac events when they could articulate their purpose and how it connected.
And this is not just Japanese culture, it's just more codified there.
But this has happened everywhere.
There was this Renaissance notion of the raison d'etre, the reason to be.
We see this in the Judeo-Christian tradition of the divine will, God's will for my life.
Why am I here? Eastern traditions have this sense of cheating nirvana, a goal, a purpose that I'm working towards. It reminds me of a story that I was reading to my kids. It was Winnie-the-Pooh, it's the original one, the good one, not the Disney one, where they made it weird (chuckling). (audience laughing) But there's this line in it, this exchange of Winnie-the-Pooh and Piglet are out for a walk.
And Piglet says, when you wake up in the morning Pooh, what is the first thing you say to yourself? And Winnie-the-Pooh says, what's for breakfast? And he asks, what do you say Piglet? And Piglet says, I say, I wonder what's going to happen that's exciting today? And Winnie-the-Pooh says, ah, it's the same thing, (audience laughing) which is cute and funny.
But what is gonna happen that's exciting today? How does my work, the thing I'm gonna do today, connect to some bigger purpose? And when we can instil that in our teams then we have this sense of us working together, collaborating and building something.
And this is the way that I think about that. I think about why does the product exist in the world? What are we trying to achieve, collectively, here? There are a lotta reasons that people have explored for why it is humanity succeeded at creating civilization. Big, big concepts.
Some people think it's agriculture, commerce is another one, but to me, it was about communication.
That is the field of anthropology, this sense of the development of literacy, of writing. That for me, makes the most sense for how we emerged and were able to create a civilization and keep that civilization functioning as a species, be successful.
Which is the idea that I can have an experience and I can codify that experience.
I can write it down and that idea that I have had, that experience that I've had, can then teleport and time travel.
It can go places that I'm not able to go and it can exceed the span of my life.
We can write things down and transfer that knowledge to other people. And so much of the technology that we have developed has been about making that a more optimised and more accessible experience.
Can we take the experiences that we've had and communicate them more broadly, more quickly? We have created tremendous institutions that take those experience and codify them as information, wrap that up into knowledge and hopefully into wisdom. But perhaps the most accelerating factor was in the last century when we divorced the idea of taking that information in a physical form and made it into an electronic form, so that we could distribute it and endlessly reproduce it in a way that has fundamentally changed our world. We took that a step farther and made it accessible so that anybody could do it and then we made it dramatically, dramatically distributed so that it could happen all the time, everywhere, between everybody.
And this is what is so exciting to me.
That we keep doing this.
We keep getting better at it.
And my job now is to try to figure out what's next and I'm always, continuously surprised.
We get to some plateau of oh my god, look at what we're doing now.
Look at how we've connected everybody.
Look at all of this exchange, looks what's going on. And what next, who knows? We will find something next to get even better at it. Probably not this, but you know (laughing), (audience laughing) we're gonna find something that's gonna happen and we are the ones that are gonna do it, is the people in this room.
That we are the people that are crafting these experiences for the next generation.
My career has been about translating what we have learned in the past into what we are doing in the future.
But now, it's native.
Now, we are the ones to figure out how this persists and how it gets better.
We have connected up so much of the world.
We're almost there, we're not quite there, but we're almost there.
And we are making mistakes, we're not quite getting it right.
These tools that we have used to connect and share our experiences, can be used for abuse and bullying, can be used to spread lies as well as can be used to spread the truth. But we'll figure that out, that's what we do. So can you find somebody to work with, to be excited about working with, to feel safe and trusted, with a team of people? I think that you can, I hope that you can and I look forward to what you build.
Thank you so much.
(audience clapping) (upbeat synth music)
