Human Skills 015 - Throwing the Gauntlet
with Sarah Drasner
Sarah Drasner is one of my tech heroes. She has keynoted for React conferences been a core contributor for Vue, and now runs Web Infrastructure at Google, which includes open source projects like Angular and Sass. She has written hundreds of articles for CSS Tricks and other publications, taught workshops for Frontend Masters, and written about SVG Animations for O'Reilly. She's also one of the only people I know to have done the "engineer to management pendulum" at the principal engineer/director level, and recently published the most human-centric book on engineering management that I've ever read.
In this interview, we covered a lot. We talked about how Sarah first came to engage with people as well as code, and tactics she's found to engage people with curiosity and empathy. We talked personal effectiveness and filling your own bucket, making sure you stay happy and healthy. And we talked about the importance of "throwing the gauntlet", challenging your teams to step beyond the comfortable and make real, substantial change.
How did you start to care about human skills as an individual contributor?
Yeah, I guess I was always a heads down engineer. I've done a lot of open source for a long time. And some people may know me from my work. I was a Vue core team member before I was at Google. I went into emeritus status when I started caretaking the Angular team, because that's just too weird.
And then before that, I was really heavily involved in the React community and gave keynotes at React conferences. I'm probably one of the only devs who's gone through. all of the major frameworks and involvement in that way.
I love open source. I love coding. That's a huge passion of mine. I think one of my favorite things to do is code.
So, in going into some of those things, what I noticed was even on the open source side, when projects that I worked on became popular, I'd have to deal with humans. And sometimes I was really bad at that, to be honest. People wanted features that I wasn't aligned to. You have to learn how to communicate with grace under fire, especially in open source.
And also for jobs - I'll just say one quick story - I used to work at Zillow and I was like heads down coding all day long. I was definitely like, "I don't want to go to meetings. Those are dumb. I don't want to talk to other people. That's dumb." I just wanted to get my work done. I just want to code.
And at one point there was like a company party and this guy came up to my desk who ended up becoming a good friend of mine and a good peer, like a collaborator of mine, he came up and he was like, "Hey, why don't you come to the party?" And I was like, "no, I want to code. I need to get stuff done. "
And he was like, do you really think that you're gonna be able to get stuff done and if you can't get along with people and get to know them? And I was like, "no..."
And that was probably the kindest thing that someone has ever said to me at work. Not... we talk about kind, not nice sometimes... that was a very kind thing he did that day.
Are there any particular tactics you've found helpful engaging with people in open source?
Yeah, I think approaching with curiosity is something that I try to do. I'm not always successful at doing, especially if something doesn't seem right. You kind of want to push back initially. I've really tried to learn how to not do that and ask questions instead. I'm not always good at that.
Another one is the fundamental attribution error. I I struggle with that one. The premise of that is basically that you attribute any wrongdoing of yourself to conditions like, "oh, I was tired that day, I was sick, I wasn't feeling good," or, you know, whatever.
And with other people, you attribute that to their person, you're like, "that person is mean, that person was bad." And that's a really... that's a big thing. Like you have to think about that a lot and remind yourself, or at least I have to think about that a lot and make sure that I'm not doing that and making sure I'm showing everybody else empathy and grace.
What have you found helpful to develop empathy for other people?
One thing that I talk about in the book in the first chapter is I think a lot started to resonate for me and gave me a system for thinking about these when I started learning about values.
Values are really interesting because when you talk about values, there's no judgment attached to it. Like if you have a value that is family or a value that is humor or a value that is beautiful mess or meaningful work, there's nothing wrong with having that as a value and not having that as a value and people have different values.
And so what I notice a lot of times when people can't get along, it's usually because their values are misaligned. And I think in movies and TV and books, what people want to do is make a good side and a bad side. And that's very infrequently the case that one person is on the side of light and the other one is on the side of evil.
Usually people either are outcomes misaligned, they're looking for different outcomes or they're valuing certain different qualities and things.
And the more you can understand someone else's values, the more you can say, "Okay, they value X, that's not my value, but that's fine. And that's why what we're aiming for is slightly different. And that's why we're not seeing eye to eye." So it can be a nice framing in a way where you're not like judging each other. You're just understanding where the other person is coming from.
Do you have any exercises you use to help identify your values?
Yeah, so with groups, what I'll often do is put a bunch of values on the board, like a big list, and then have everybody pick either three to five, depending on the group and how much time we have. And then people speak to their values and they say where that value resonated and came from for them.
Sometimes values are things that you've always had and you don't know why. Sometimes values are something that you developed over time.
Let's say learning is a value now, but it wasn't when you were a kid and you went through some process where you learned that was important to you or some event happened in your life to make that important or something didn't happen in your life where like you were let down because of something and now you really value the presence of it.
Talking through that as a group can be really useful. Every time I've done it with a group of people, it's been really grounding and people go, "ohhhhh", and there's a lot of insights and then people can kind of match up and be like... "Oh, that's why when we talked about X, like this, Y happened."
For myself, you know, I'll be honest that I've, you know, previously in time had a hard time making boundaries for myself. I'm the kind of person who is a hard worker. You give me a challenge and I'll run towards it. I'm easily nerd sniped.
And as I started working in the community more and more, people wanted more and more of my time until I didn't have any left, and I kind of ran out of tools for what to do. And I wasn't seeing my family or my friends as much as I wanted to.
So I actually got a coach and she really helped do some work with me that was kind of tough love of like, "Here's what you say your values are. You say you care about coding, you care about your family, you care about your friends, you care about this, but you're only making time for coding. Are you really honoring your values?"
And what tends to happen if you don't honor your values over time is you start to burn out.
Or if you don't like your job, sometimes it's not because you're working hard, it's sometimes it's because your values are misaligned with your leadership or your values are misaligned with where the company is going. That can burn people out just as much as hard work can.
And so, I've done some exercises with myself to make sure I was... doing things to honor my values. So one that I did to figure that out was to write down what I think my values are into four different buckets. And then I would make a list of all the stuff that I was working on. And I would have to map it into those buckets.
It could cross multiple but then I would notice when something wasn't hitting any of the buckets.... And I'd be like, okay, those things gotta go.
At the time I was doing a lot of work for CSS Tricks. CSS Tricks actually hit almost every bucket for me. And I was like, "Man, I should be reinvesting more of my time into doing stuff writing there or like Vue core responsibilities."
So it can also be a good reinforcing thing of like, "oh, OK, now I know, this is something I'm doing on the side, but I appreciate now that that's really helpful."
How do you manage to be so prolific in your writing?
It kind of comes down to the way that you think. When you're a principal level TL, a lot of your work ends up being in design docs in order to communicate an idea. Sometimes my technical writing is a breadcrumb trail for myself because I solve the same problem twice now. And I'm like, "man, If I don't write this down, I'm going to solve it again for a third time."
I have this post that's like, "how to build a Chrome extension". I wrote that because I kept making them and then going like, "how do I do that?" Reverse engineering my own work because enough time had passed.
And it's also for other people. I learn a lot from other people. The way that I've learned how to code and evolving that... I mean, evolving your coding discipline is a constant process, right? I don't know about y'all, but I'm always learning. I'm always learning new things. And I have to rely on people putting things out in open source or tutorials or writing.
And so for a long time, I consumed that for probably 10 years of my career, I just consumed that. And there was a point where I said, "I need to start giving back a little bit too, because I can't just only consume other people's material."
No judgment for other people, but I just felt like I was taking a lot and not giving enough. And so, some of that is definitely that and that if I could even just write something down that saved other people some time, that was really meaningful use of time for me.
I think a lot of writing the book was that I was mentoring a lot of people and I noticed that people came to me with the same things over and over again. And I was like, "there's no way I'm going to scale myself jumping on one or two calls every month. I think it's better if I just write these down and if people want to read it, great. And if they don't, you know, no worries."
What are the similarities between working as a principal engineer and an engineering director?
I think something similar that I see in principal level IC work and principal or director level or VP level strategy is the idea of throwing the gauntlet. When you're at that level, sometimes your job isn't dealing with every single how or executing every single how.
That was really challenging for me as I was learning and developing and moving up. because I want to work on the house sometimes. And sometimes I know I'd be faster at it than other folks who are just learning. And I had to learn a lot of patience and also learn how to trust other people to execute. And that is a lot easier said than done if you're like a perfectionist or something. Thankfully, I have wonderful teams that are really deserving and go far beyond that trust.
I think both in principle and director level, you are throwing the gauntlet. A principle level activity for something like that would be to design an entire architecture of a system, but not necessarily execute every single part of it. So you're kind of writing a design doc that's high level. That's like, "here's how everything could work. Here are the reasons why we might do this. And this is here are the risks. Here's conceptually how all these things plug together."
And then you work with other people who are going to execute the smaller bits to make sure that you're validating your approach and that it's going to solve the problems that you think and that you're not gonna run into massive tech debt that you may not know about or something like that.
When you're a director, you do the same kind of work. You're still throwing the gauntlet and you're saying that there's strategic direction to go in. I'll give an example of that on the director level. So I mentioned that one of the teams I run is the Angular team. When coming in from Vue, at first I was like, "are they going to be weirded out that I'm from the Vue team? How's this going to work?" And I was really pleasantly surprised to find a humble, thoughtful, curious group of people who are hungry to evolve.
And so what I ended up doing with that team when I first joined was, I wrote up a doc of all the things that I saw coming from community to community and just asked them a lot of questions about "what was the design idea behind this? Why are we doing X, Y, and Z?"
The asking of questions is interesting. From their perspective, it gives them an opportunity to either articulate strategy or articulate "Well, this made sense eight years ago, and maybe it's the right place for us to innovate and things like that."
And then even further throwing the gauntlet of like, "Hey, I think we're here. Do we agree that we're here?" And they go, "yeah," or they go "no," or whatever, but usually we align. And then say like, "I think we gotta go here, right?" And they go, "yeah." I'm like, "what are the things that we need to do to go from here to here? I think that there are some things in this area that could be revisited. Do you agree?" Yes, no. And we talk about those. What are the things that we need to do to iterate on those things?
And one of the outcomes of those is Angular signals. That's the product of many of these kind of conversations. The Angular team is so good at dealing with me throwing the gauntlet. They're so kind and thoughtful. And to be clear, they're the ones doing the work. They're the ones designing signals and deciding that that's the ultimate direction.
I'm asking questions and like kind of, you know, poking on things. So you can see how like the principle mindset and IC world is not too dissimilar. It has... curiosity pieces, it has like, here's the overall strategy that we're thinking about. It has other people executing more fine grained work... and all those pieces are critical too.
So it's a lot of that orchestration and to your point about it always being human, so much of that is communication.
What makes a good gauntlet when you are "throwing the gauntlet" to challenge people?
I think it changes depending on the team. I'll give another example and then I'll pull it back.
One of my teams is the BuildServe team... and Google's infrastructure is different from external's infrastructure. So we can't wholesale adopt something like ESBuild or Parcel or Webpack or anything. But even though we cannot change those things wholesale, the thing that I asked them to do was, "hey, go, I'll time box some time for you, go reverse engineer those things and come back and let me know, did you learn anything? And is there anything that we can evolve?"
So you could see how there's difference there, right? I'm not saying to the BuildServe team, "go change your direction." In the Angular case, I am sort of... I mean, I'm not telling them what to do. I'm just... Or like another question that I asked another team was, "are we set up for success for the next 10 years in this direction? Think about it and come back to me and think through these things."
And they would come, they came back to me and they're like, "actually, no, we've got to do this and this and this."
In all those cases, I'm not coming to them and saying, "you need to do X." I'm just asking a strategically placed question that they are empowered to answer. They could come back to me and be like, "yeah, we're totally good."
It's still in their hands to decide the direction and execute. But the strategy is something that I'm like kind of throwing the gauntlet, like, "I think that we need to consider this. Come back to me."
Recommended Resources
Straight from Sarah in her voice
Range is a great book: https://www.amazon.com/Range-David-Epstein-audiobook/dp/B07N6MPWLS
Michters is a great whiskey: https://woodencork.com/collections/michters
Another great book: Thorsten Ball's Writing an Interpreter in Go, Writing a Compiler in Go
Another: Randall Monroe: Thing Explainer
Links to Sarah
Sarah’s book: Engineering Management for the Rest of Us