Debugging is for Human Relationships, Too with Amir Shevat

Amir Shevat has led teams at some of the most well known tech companies out there, including Slack, Google, and Twitch. Today, Amir is Head of Product at Twitter’s Developer Platform. Amir joins the show to share his experience of the effectiveness of a GM model and just how important it is to listen when joining a new team.

What is SWIMM UPSTREAM?

The Swimm Upstream Podcast is a collection of conversations about knowledge sharing, code documentation, change management, scaling dev teams and more. Our guests come from all over the tech world, with some really interesting insights, stories, and… coffee hacks. Join Tom Ahi Dror, Co-Founder of Swimm (a Continuous Documentation platform that streamlines onboarding and knowledge sharing within software engineering teams), as he talks with some of the most inspiring engineering and dev team leaders in the industry.

Tom 0:00
They say that change is the only constant in life. On this season of Swimm Upstream, we're breaking down specific instances of change in software organizations when both technical and human aspects were involved.

Amir Shevat has worked at some of the biggest names in tech: Slack, Google, Twitch, and now he is the head of product for Twitter’s developer platform. In addition to Amir’s work at Twitter, Amir is also an angel investor and an author. Welcome, Amir!

Amir 0:35
Thank you for having me. Very exciting to be here.

Tom 0:39
Alright, let’s dive in. Let’s kick things off with some warmup questions. What have you been listening to on Spotify?

Amir 0:51
I am really boring. I listen to "Songs to sing in the shower" which is a playlist that Spotify has - just like happy songs that they collect, and they update that science. Like, I put my faith in the algorithm of choice. And that's my go-to playlist.

Tom 1:13
Okay, I'm gonna check that out. That sounds good. Happy is good.

Tom 2:03
Please tell us a bit about yourself. We did the introduction. But where were you when the story that we're going to focus on transpired?

Amir 1:28
So, I just left Slack. As you recall, I started Slack very early on, and left Slack when we were about 2000 people - and joined AWS to a company they acquired called Twitch. And my role was the VP of the Twitch Developer Platform. So like all the APIs and the tools that developers use to build on top of Twitch.

Tom 2:00
Did you have a big team? What type of people were on your team, product or developer advocates?

Amir 2:07
So the way Amazon works, it's called a single-threaded owner, meaning that it's what's called today a GM model, which is a single person - and all the cross-functional teams report to that person. So I had engineering under me and I had product under me. And I had marketing, partnership, and developer relations.

Tom 2:35
Basically like a company, right?

Amir 2:38
Yes, the GM (general manager) model. We have a GM model on Twitter as well. But like the GM model, it empowers a person to do their entire job really fast. It has the downside of like, you might have duplicates because if you have multiple GMs with marketing, there's not a lot of like synergies between those PMs. But you get a velocity of execution, which is really important in these models.

Tom 3:06
Okay, that makes sense. And it also sounds like it might help avoiding the kind of stuff you hear about startups being acquired by really big corporations, right?

Amir 3:18
The way it works is that there's no metric management. It removes the metric management. So like a product manager or engineering manager does not need to negotiate services, from marketing, from partnership from all the rest, everything reports to a single leader. And at Twitch, it was very effective. At Amazon, it's very effective because you can't go to your manager and say, “Hey, I didn't do my job because that team didn't give me the services that they need.” All the services are under you. So it's one head to bash if you'd like.

Tom 3:58
Okay, so that sounds like it could reduce politics significantly...

Okay, and that's a good segue to ask you, like tell me, like the background of when the change that you wanted to talk about happened?

Amir 4:12
So, when I join, I usually join and I do a listening tour. I hate it when a leader comes. And they immediately say, Okay, this is the change, this is what we're doing. Everything is different. You know how it goes. Like, going around and saying, “This is my territory. I don't like that I don't like territorialism.” So what I do is I started by listening to people. And I spend about two weeks listening to all my directors, all my engineering managers, talking to engineers, and to PMs all across my organization and marketing, of course, all the cross-functional. And the realization that I came to is that there is no collaboration and there's this bro-mentality. So, the person like that yells in a meeting gets his thing. And people and PMs do not share a roadmap. And there's a competitive behavior between PMs because they don't collaborate. This could work for other leaders. For me, I don't - I can't work that way. I need to work in a place where people collaborate and help each other and let other people express themselves in an empathetical way. I came from Google and from Slack, and that's the way people behave there. There are other places that are notorious for being more militant in their interactions. But I can't work that way. So I had to create a change that would let people work in a more collaborative way.

Tom 6:07
Okay, so it sounds like you wanted to work against two very strong forces, both, you know, how people got used to working in the organization, and also what they know, from their peers and other organizations. Right. So how does one go about even starting to think about changing something like that?

Amir 6:26
So I think the first thing is to recognize the problem. To say, hey, like, what I've heard from you, this is not me passing judgment, this is what I've heard from you, is that we have a collaboration, challenges. Like we're not sharing roadmaps between directors, we're fighting over resources. People have told me that they can't speak in meetings because other people yell, and they can't get their - especially junior people and especially diverse audiences had a hard time saying and doing what they're what they wanted to do. So first of all, acknowledging the problem with my direct reports, and in all hands like telling people, “Hey, listen, I want us to have a single mission, and a single vision and a single strategy and I want us to work towards it together.” So that's acknowledging the problem.

Amir 7:29
Then I'm an engineer by trade. So I look for like root cause analysis. Like what is the bug that is driving the problem behind this? Because usually, people from my experience are much more collaborative when they have a single mission. So I looked at each of my directors, and they all had very different missions that they were trying to solve, and even a different audience that they were solving for. And the second thing I did was to work with them to create a single mission and vision and strategy and to connect all the technical infrastructure and roadmaps and everything that we do together into a single thing that we all want to achieve. Having a single audience and change is hard. Some people did not like to change some people left my organization. But from my perspective, it was easier and, and made people happier and more productive by having a single mission and vision, and strategy.

Tom 8:41
It sounds like you didn't meet this necessarily head-on with education. Like I want you to behave differently. I want you to speak differently. You started with the root cause and it sounds like that made it easier because you're not trying to change a person or their like specific behavior. You're trying to take away the reasons why are there getting into that confrontational place in the first place.

Amir 9:07
100% I think that like if I tell people to change their behavior, but the situation stays the same, they will show me that they change their behavior, but they won't actually change their behavior. And also like working by example is really important. One thing I've learned, so I did a VP course at Amazon and one of the gems I collected there was to let other people like the junior people speak first. And I was very inspired by that because that basically solved the yelling in meetings type of exchange. So when there was a review - and in Amazon there's tons of reviews - I started by letting the most junior people speak, and then go from there to the senior people. And that created a much more inclusive environment where the junior people had a voice. And usually, the junior people were much more connected to the problem that we're trying to review, and much more able to make an impact and a smart choice there. So listening to the junior people, junior engineers that are closest to the problem was usually very effective way.

Tom 10:24
So in these types of situations, in my experience, there are things as a manager that you get into when you get into this. There are things that you like ideas you come with and maybe you hope that they also come from the bottom, right? And there are things that completely surprise you that you like very much - like were there both of these?

Amir 10:51
Of course, there were ideas that I came in with, like strong conviction that something should be done. And they were a complete failure. Like they didn't work because it was rejected. I tried to consolidate all the products under a single umbrella name, for example. And I was a complete failure. Marketing hated it, my directors hated everybody. Other than me, nobody liked that schema. And basically, I said, “Okay, I disagree and I commit to your thoughts.” One of the key things that people don't understand about the phrase disagree and commit is that managers should, like disagree and commit with their teams. It's not like I listen to my manager and now he told me what to do. Many times, it's like the manager, recognizing that the team knows much better than he or she about the situation and committing to their way of doing things. Like team knows best.

Tom 11:58
So we've had people on this show that told their story from a very different perspective than you as the general manager. Their point of view was one of the junior developers and they spoke about how to get managers on board with their ideas. Did you see any effective tactics for people under you to recruit you or other people in leadership positions?

Amir 12:33
So there's multiple ways to recruit. I think my most effective way is to show rather than to tell. So for example, whenever there's a hack week or an internal hackathon or a design sprint, I really like the fact that like my engineers, when they have an innovative idea, they actually implement it.

And this is how I work with my upper chain. Like when I want to show something to my leadership, I show them, I don't know. And, I think that's very, very effective. So like, “Hey, we've done this change. Look, let's add it to the roadmap.” And that's, that's a much easier way than starting to complain about something and saying, this needs to change.

You can definitely - if it's something that you can’t implement and show. Then definitely raise your voice. But if there's a way where you like, actually show me the things that you want to build, that is a much more effective way.

Tom 13:40
Going back to the change that you were trying to push in your organization, you mentioned several people left. So what were the biggest challenges that you faced, I mean, it sounds like you were building this from the bottom up in a very smart and effective way. But still, what were the biggest?

Amir 14:06
The biggest challenge was attrition, because people who did not agree with the strategy, people who did not want to change, people who did not like to collaborate - who wanted to be non-collaborative - were not happy in the organization. And you need to accept that that is okay. I also left organizations where I didn't feel like I fit in anymore. So it's okay for people to leave when things change. That's part of what we do. And as a manager, you need to empathize with a person and say, okay, like, either help you find another role in another organization or give you a recommendation to work somewhere else. But that was like, there were days at that time where my kids would ask me who left today? That was depressing. But we had about 10% attrition. That's like a lot of people - at the time that was like 15 people.

Tom 15:04
So do you recall any situation where instead of someone leaving you managed to flip the way they thought about things - from being very much against, they became part of the change?

Amir 15:19
Yes. So I'm not going to name names, but there was the director that thought that after the change, their ability to make an impact was blocked. And if you can't make an impact, you can't be happy, you can't be promoted. There's a lot of things that are associated with that. And the way I solved it is through having a lot of one on one meetings with them, and also building a growth strategy for them. Saying, “hey, let's carve out what you can actually make an impact on. Let's empower you to make that impact. Let's see how we can create a growth plan for you.” And for me, that was very important, because I really like to retain, even if they don't agree with me basically - even more if they don't agree with me - because if they only agree with me, I don't get a contra - I get confirmation bias. So I like people who do not agree with me. And that gives me the minority reports, basically.

Tom 16:27
Throughout this process, did anything surprise you? You know, something that you didn't think would happen in this scenario? I'm assuming you expected a lot of the challenges, but was there anything that was surprising?

Amir 16:43
I think the thing that surprised me is how happy the engineers were when they felt empowered. So once there was a single mission vision strategy, an engineer could outline what they're doing now and how it impacts the strategy and they had clear roadmaps that were not conflicting with other roadmaps. So there's no like dependencies that made them work slowly. How happier they were. I think the key there was like, if you give engineers a clear roadmap, a vision, and all the tools they need, they will be happy and productive. It sounds kind of intuitive. But when you're dealing with a lot of change, you don't think about that. And that made me very happy.

Tom 17:40
Okay. And it also sounds like if you're having trouble with a particular team, or person that are unhappy, you should check these things that you just mentioned, and see if they exist and if they're all in line.

Amir 17:50
Oh of course. And, of course, again, debugging is not just for code. Debugging is for human relationship as well - way before we add debugging for code. It's kind of hard to debug because there's like, artificial intelligence that goes in the way so and that's always hard to debug.

Tom 18:16
Let's talk about this retrospective. We're talking about something that ended around two years ago, right? Yes. So you know, there's a huge challenge in changes, particularly changes so significant in organization. Another challenge is making that change stick. And when you look back, what does it look like the change stick? Is the culture still what you hoped it would be?

Amir 18:40
So I hope so I'm not in that organization anymore. What my friends there are telling me, that they kept the relationship between each other. And I think that is important. I think that the people, I still have a good relationship with, which are like everyone there still like are friends with each other. And that's important. And that's empowering. And the people that I thought were going to be the shooting stars are actually the shooting stars. And that's another, when you do an analysis of your organization, you map the people that you think will be very successful after the change. And that proved to be the case. I'm sure there's always like, nothing is bulletproof. I think here sometimes you make change and in it reverts. Sometimes you make a change, and it's not the right change. There are organizations that perform better by not being super collaborative. And even being super collaborative has its downsides. If you're super collaborative, sometimes that impacts your velocity, because you need everyone to agree to what you're saying. And that's also not super useful. So finding the balance is important. And I hope the team has found a good - but I'm following them on Twitter, and I'm seeing the amazing things that they're shipping. So I'm proud and happy.

Tom 20:16
Thanks, everyone for tuning in. That's all the time we have for today. To read episode transcripts, check out our past season, suggest an episode or join our growing community of developers. Head to swimm.io that Swimm with two M's dot IO.