StaffEng Podcast

Matthew Bilotti (Twitter)

On today’s episode of StaffEng, we speak with the formidable Matthew Bilotti who works as a Senior Staff Software Engineer at Twitter and has been at the company for 11 years. Matthew currently leads a team that plays a critical role in user safety. Matthew has also taken on a key role when it comes to mentoring junior members at Twitter. In our conversation, Matthew talks about why he’s spent so many years at Twitter, his deep passion for teaching, and why the work his team does is invisible until something goes wrong. Matthew also elaborates on what goes into hiring a new senior staff member and why, at Twitter, they make it possible to easily switch teams to help retain the employees after the company has spent so much time investing in them. For all this and much more, join us for a riveting discussion on leadership, mentorship, and how to balance idealism with realism in a mission-based company!

Links

Listen

Download Episode

Transcript

Note: This transcript was generated using automated transcription and may contain errors.

David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Aromas and I’m joined by my co host Alex Kessinger. We’re both staff engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.

Alex: Yeah, this was an awesome interview with Matthew Bellotti who is a senior staff software engineer at Twitter where he has worked for over 10 years. One thing that came across in this interview was how much Matt cares about mentoring, which for me is always a challenge. It’s great to hear how others approach it. So let’s get into it.

David: Okay. Well Matthew, thank you so much for taking. It’s really nice to meet you. If we could start by having you tell us just kind of a bit about yourself in your own words, who you are and what you do.

Matthew: Sure. Thanks Dave and Alex, it’s really nice to meet you both too. And thanks for the invitation to be here and to talk about this kind of stuff in public. I think it gets a lot of play in my one on ones, but it should be talked about more. And so who am I? What do I do? I’m a senior staff engineer at Twitter. I’ve been there for a very long time. I recently celebrated 11 years. So I know this is very uncommon industry wide to have tenure of that length. But one of the reasons I stayed there that long and still stay there is because of the opportunity to grow my career. First to staff, then to senior staff, maybe contemplating principles at some point in the future and the opportunity to learn the skills and work with the folks to make that a reality. Those opportunities presented themselves at Twitter. And I mean I like Twitter, right? Twitter is full of really wonderful people and I think we are an important service for the world to have and it is kind of fun solving the problems. We’re not so big that you still don’t have a large impact on the user’s day to day experience. We might be one of the smallest of the quote big unquote companies. Cool.

Alex: One of our questions that we like to ask everyone is like what does a typical staff plus engineer do at your organization?

Matthew: I feel like the role is so highly nuanced that it might not be atypical. I can give you some generalities. Certainly this is the kind of stuff I tell my mentees. So I think, you know, a staff engineer, staff plus engineer is a leader and an influencer, not a people manager. And the influence and guide that our staff plus engineers, you know, give us are because they are. They’re highly knowledgeable technical experts and their advice is highly grounded in the needs of the business. Not just now, but many quarters, perhaps years sort of into the future. And I also think a key element of the role is being an excellent communicator. Right. So I’m not your manager. I can’t tell you what to do, but I can appeal to our shared goals, business goals, stuff we need to get done. I could say the work leads us in this direction. There’s risks over here. Let’s try to avoid that. There’s probably a sweet spot of investment for, you know, to return if we go in this direction. But I try not to say no. I try to say yes. And right here are some things you should be aware of. But, you know, at a certain point, you’re leading the project and I’m a resource, sort of for you.

Alex: Yeah. It’s impressive to hear that you’ve worked there for 11 years.

Matthew: I know. I can’t believe it myself.

Alex: Do you feel like there was any particular projects or anything that sort of allowed you to grow as a senior? I see, you know, especially going from whatever was before staff plus to staff plus.

Matthew: Right. Well, I just want to say that the projects that I did that got me promoted or at least proximate to my promotion, they weren’t always my best work and they weren’t always, you know, a complete example of operating at that next level. Right. I think I got promoted for showing sort of directionality. I got promoted for being a multiplier and an enabler. I think that was my senior staff promotion, guided an arc of work that took 12 months with several teammates in the SUI2 and senior SUI ranks. And also an intern who is great and still works at Twitter as a full timer and is wonderful that year. We came in January with a complete roadmap. We had thought of the year before and an excellent product manager explained to us that there was a massive broken window that was leaving many monthly active users locked out. And she is also wonderful and is back at Twitter now. We scuttled the whole roadmap and we pulled a few folks together and we delivered it. It took till December, like right about holiday party time. We landed it and we didn’t even expect a couple 100k users to be released. From. I don’t want to be so specific about what we worked on, but it. It did enfranchise a bunch of people that we didn’t realize were being locked out of the platform due to some of our sort of challenges and security measures that just weren’t sensitive to the fact that folks, you know, recycle phone numbers, you know, move to a new city, go to the AT&T shop, get a new phone number. Who knows who had that before? That person could have been locked out of Twitter.

Alex: Sure.

Matthew: And now we fix that. So you’re not.

Alex: That’s really cool. For what it’s worth, I think a big theme that we hear about a lot is learning. And so taking the time to acknowledge when things didn’t necessarily work out as well as they could have is probably a very big part of growth. I think, just in general, you mentioned the word directionality, and I was just curious, is that something that means something inside of Twitter or is that something that you have developed? What does that mean to you?

Matthew: Oh, no, I brought up that word because I feel like it used to be industry sort of practice back in the day to say, well, if you want a promotion to staff, just operate as staff for six to 12 months and then we’ll see about the promotion. And I don’t think that’s the case any longer in at least larger shops or maybe at least Twitter. I think we try to recognize people’s velocity towards growth or the derivative or whatever it is they’re going to get there. And we don’t really gatekeep the upper ranks of the IC ladder as maybe strictly as one would have, if you’re a small company and a promotion is a very risky thing. Right. If you promote the wrong person, does that person have undue shape on the direction of where you go? You probably want to select conservatively at a smaller place, but you have advantages because if you’re a smaller shop, you can make a claim to that level of growth as a company. For example, if you’re pre ipo, that a company like Twitter couldn’t make that claim now. So when we go out into the open market and we try to hire senior staff plus engineers, which we do, I wouldn’t say we have any more, any less success than. Than other companies, because these folks are often fairly happy where they are because they have a lot of control over how things go and they often feel like their work is not done right and they’re a necessary mainstay of the engineering org’s direction and success. I Think that’s reasonable. But, you know, you need to be able to say, hey, I can hire you at senior staff. You don’t have to come in at staff with 12 years experience, but then work your way up over the next five years to senior staff. We have that role open now. Right. So if both of you are looking for roles, we’re hiring, had to do it.

David: On that note, sort of the idea of like, because you’re right, that is a common idea that I’ve certainly heard before, is like, if you want the promotion, you sort of need to demonstrate yourself operating at that level. I guess I have two questions about an approach which differed from that. One of them is like, how do you identify if the person isn’t actually already operating at that level? And then the other one is like, you mentioned sort of the idea of the riskiness of promoting the wrong person. What would happen to Twitter if you promoted the wrong person?

Matthew: Well, we don’t have a mechanism for releveling anybody other than pip. I’m not aware that that’s common in the industry. I think that’s why folks were conservative early. You know, I mean, if you really, if they came to me and said, oh, Matt, you had a bunch of kids, I work a bunch of flex time now. We’re just not seeing that senior staff level contribution any longer. If my manager were to say that to me, which they would not, hopefully that would be a signal that I’m being shown the door. Right. So it’s almost useless as a tool to shape your engineering org. I think that’s a completely off the cuff opinion. But the worst thing that could happen is you’ve got someone who shapes things in the wrong direction. So someone who greenlights random things that will be, short term, shiny in the short term, that will pose massive amounts of technical debt in the future. I feel like where I sit at Twitter is I’m sort of the old guy lashed to the mast saying, no, I’m old technical. Because I feel like it falls on our team to sort of clean up and close the loops around a lot of the things when terms like velocity are thrown around.

David: What is your team, by the way? We didn’t cover that.

Matthew: Oh, yeah. Well, my team is called health. A lot of places call it safety or product safety. I think we’re responsible for a lot of the treatments that you see. When something is, for example, nsfw, there’ll be interstitial warnings and things around there, and those things are there for the safety of the general user of Twitter. There is a lot to it. There are misinformation warnings, there are warnings against attempts at disrupting integrity of elections. And these things are all playing a very important role in the business. I do think they’re critical. I also think they are tied into everything. It is the spider team with tendrils that touch every single portion of the product serving stack. It’s kind of amazing and kind of bewildering to be at the locus of all those things. So that is my team. And what would happen if we hired the wrong person at senior staff? Well, we usually don’t hire the wrong person. I think we once had somebody who was extremely senior and very, very bright who joined our team and they didn’t sort of like it. So whenever I’m involved in any kind of hiring panels, I like to give the disclosures and assess mission fit up front. I mean, honestly, it’s the kind of team where Jack Dorsey won’t take any notice of you if you’re doing your job well. But if you’re doing your job not so well, there’ll be input, let’s say. So it’s nice to be there. But in those cases, when the folks are not a good fit for us, they either leave the team or they leave Twitter, you know, so we make it relatively low friction to change teams.

Alex: Right.

Matthew: You don’t want to spend all this time hiring someone at any level, right? You’ve sold them, you’ve invested in them, you’ve trained them. I don’t know about you, but our documentation is very sparse. So the training is a very much a one on one or many on one. Let me show you what I do. And it takes a long time. It’s an investment, actually. It builds great relationships. So anyway, you’ve done all that and the last thing you want is someone to say twitter. Not for me, I’m leaving.

David: Right.

Matthew: So we have this process we call branch out. As many things are our bird metaphors at Twitter, as you can imagine. And birds like branches, we think. And that means you can, in a relatively low friction way, move to another team. And some folks have done that without any kind of hard feelings. I don’t think we’ve had anyone really at a high level in the engineering ranks that has done something really close to malfeasance are damaging the business. And if we did, I wouldn’t be able to tell you that in a public forum. There would have to be a private forum and probably some beer and there could be some stories about what didn’t go well. That one or two times, but they’re, they’re relatively few.

David: But of course that, yeah, that’s never happened. So there’s not even a story to be told.

Matthew: I’m sure it’s never happened in your guys stories either. So.

David: When you think about sort of like your day to day work, to what extent are you sort of helping teams drive specific projects versus sort of team oriented or organizational oriented work like planning, training, recruiting, mentoring, etc.

Matthew: Yeah, it’s all of the above. I think the do you directly manage a project like I was telling you about, that 12 month arc of work? That is the mode where you keep the big picture. You’ve broken the task down into small portions, you’ve distributed them across the team. You write maybe 25% to a third of the code, but review all of it as folks come in. You explain how their things fit in, you help them understand the choices that they’re making, you help them figure out what the next task is and then you do the communicating about it and you let leadership know and all that stuff and you eventually get to the lay on the plane successfully. I don’t do that every day and it might not be the highest leverage thing for me actually to be doing right. So that and how much time do I get to individually write code, which is a very small slice of, you know, my time, though enjoyable as an avocation, that is also not the highest leverage thing that I’m really supposed to be doing. So I’m really supposed to enable other people to do those things and more. And you mentioned a bunch of the tools in the tool chest to do that. Mentoring is a big one. Planning, writing and evangelizing a vision. So you can evangelize in a document form or in a public speaking form. I also we have a Twitter university inside where we teach ourselves things and I’ve been running a class for a while about health engineering. What it does, what it doesn’t do, where the intersections are that tends to be frequented mostly by new hires, you know, but it’s still, there’s still value there sort of in leveling up the team, sort of in a broad sense. There’s also a thing, I don’t know if you mentioned this or not, but a thing that occurred to me that you find at the high levels of IC roles is like organizational service. So there’ll be promotion committees, there’ll be technical committees, folks figuring out anything from what technologies we should adopt or not adopt to what should the hiring strategy be for senior staff plus candidates. The questions would be Different. What skills would you try to assess? I actually worked on that one a little bit. A new thing that’s come onto my play recently. I recently realized that our engineering mentorship program had flagged because a key person who was driving it left. And I learned this by advising people to seek out the program. Right. You know, folks will say, well, how do I get mentorship? It’s like, well, that’s actually the thing we have a program for because it is hard to find. Right. They will match you and make sure folks had a productive match and do sort of follow up assessments to make sure it’s going well. All that good stuff you’d expect from a top shelf mentoring program. And it hadn’t been running because of someone who had left the org. So I said, what right I have to get involved? And so I just started emailing people that I know had worked on it in the past who that who might leadership and development side folks who might provide an umbrella where we could restart this program was like, yeah, I want to restart that. Mentoring people is probably the best thing you can do. Well, it’s one of my favorite things to do if you want to have great senior staff and staff engineers in your org is protect your time to mentor. So because I don’t scale right, I can’t mentor high tens of people. We should have a mentorship program where everybody who is staff plus has one mentee and we keep it in rotation so people get different perspectives. So we’re going to start that.

Alex: That’s really cool. And it sounds like there’s like a wide variety of things you could work on. And I want to touch back on that in just a moment. But one of the things we like to talk about are sponsoring mentoring and leadership. And so. And you mentioned that that’s something that you, you like to do and that you think is important. You know. Do you think you could talk a little bit more about like your approach to mentoring?

Matthew: Oh, my personal approach is other than prioritize it, which I seem to have the earned a little bit of autonomy to do that. I don’t know if it is or isn’t on the career ladder, but I think it should be. I think it’s a really important part of how we level up our own community. And you want that, right? The person working next to you, you want them to be as excellent and as best prepared as they possibly can be because that’s the kind of person you want to work with. So want to help them with whatever they need. So my personal strategy for mentoring is kind of reactive. I feel like I have a lot of set pieces about things I’ve seen in the past and that when I identify someone as sort of slotting into one of those tracks, I bring out a couple of set pieces of advice, things that I’ve observed or learned from other people or things that have happened to me. So I tell those stories pretty freely. Can’t tell all of them here, but sort of like in our one on ones I tell the truth, right? And sometimes the truth is not awesome. Sometimes things didn’t go well. Sometimes things are not equitable, Sometimes there’s conflict with leadership, sometimes mistakes are made. So I try to kind of lay it out there and see if folks can key on any of those things. Ask me questions and kind of like I asked you before we started recording, which is please elicit the knowledge from me because I don’t know what I know and I need to wait for someone to ask the question and then I go, oh yeah, let me tell you about that time.

Alex: Cool, Miyam. It makes me want to be mentored by you.

Matthew: Oh, that is a very kind thing to say. No promises about whether I’m any good, but what I at least make up in the lack of quality is in the quantity. I never say no to someone who wants to chat at any level. Really.

Alex: Going back to sort of the organizational stuff that you were talking about, a common theme that we hear is there’s always more things you could work on than you have time for. And that as you go up the track, organizational impact and sort of like really looking forward into the future becomes more and more important. Do you have a particular approach to understanding how to pick the right projects that have the most organizational impact and that make you aligned with what the organization wants to do?

Matthew: I would say that I don’t really have the intuition that would allow me to choose the project that makes the biggest splash where, you know, folks start ladling out titles like Principal. Right. I don’t have it. What I do have is a sense of my immediate area, which is, I think, fairly deep. And because it’s super highly intersectional with not just what we do on the product side, but even fundamentals of the business, it’s essentially an advertising business, as you probably were. I know what to do in those spaces that I think are the right things. And I do know, I think I have a sense of what not to do that would be either a very risky thing to do or something that would have such high confidence bands in the return on investment that it’s not smart to go from there to hair hair to there right away, but to take maybe baby steps in between. I don’t always get my way about that. I feel like I’m not here to say no and slash people’s roadmaps, but I do try to get people on an incremental track of stuff that it’ll eventually be good for our users and that means it’ll be good for our business if we do it right. Again, the specific stuff we work on is highly wrapped up in user trust. And even if it’s not wrapped up in user trust, it might be wrapped up in do governments think we’re treating our users properly? And those governments are all around the world with all different kinds of privacy and data protection regulations that affect us, kinds of regulations on what is or isn’t lawful speech in those jurisdictions. And we have built out all sorts of stuff to be really responsive to that. At the end of the day, if we’re sued out of existence or blocked from operating in certain countries, we’re not serving that person who needs to document injustice going on in their communities or whatever it happens to be. Twitter is a vehicle for citizen journalism. So if we keep it safe and we keep it up and running and healthy and happy, then we’re doing. That’s the story. There has to be one. It’s part of the sustainability, three legged stool. You want to work at a place where the company is neutral to positive in the world. And so there’s a story to that. The degree to which you buy it is up to you. But if Twitter gives voice to the voiceless, then it’s a zone for free speech. To the degree that’s possible, then it’s doing something that’s positive.

David: I want to dig into that a little bit actually. The idea of narrative guiding mission and the impact that can have on organizations. Because while you mentioned it earlier, staff engineering is all about influence. And one of the things that affects your ability to influence is sort of like the extent to which people around you, people that you work with, are aligned on the mission. So I have found it interesting working in a mission driven organization, sort of the balance that maybe needs to happen as a leader between really being truly bought into the mission. And it sounds like you are, while also being a realist, which it sounds like you are. Right. At the end of the day, these businesses exist, certainly they have a mission, but they also want to make money. And there’s, you know, there’s lots of factors at play and I find it important when I’m dealing with folks to try to present that authentically, right? Yes, I believe in the mission, but also like I’m not necessarily drinking the Kool Aid. Right. And maybe that’s sort of a cynical way of expressing it, but does that resonate with you and do you sort of have those, do you sort of sometimes think about the right balance of how to present yourself as a leader when you’re sort of presenting that mission?

Matthew: Yeah, I mean, I try to keep it pragmatic. So as I mentioned earlier, we’re not the kind of team that gets a lot of visibility. So specifically on our team, if you’re going to be happy here, you got to be a little bit self motivated. So when I was trying to hire some folks into our team, I would be screening up front to try to understand do they want to combat, you know, racism on the Internet, sexism on the Internet. Right. Hate speech and other bad things. If you do and you can be self motivated by that mission, you will be a good fit here. And the pragmatism comes in. And so far as you’re not going to get a pat on the head for doing this, right, you can’t prove a negative to the board or to Jack Dorsey, right. I mean, I know he understands sort of academically that we exist and certain members of the staff of Twitter definitely understand quite viscerally that we exist and aren’t doing important things to keep us where we’re at. But yeah, you’re not going to get recognition for this. And it might be, that might be a thread to pull on later because recognition often translates to career growth. But if you’re in our team, right, and you can be self motivated and you understand that you need it, because there isn’t going to be a lot of kudos all the time, then that’s fair. And I like to disclose that up front because I really don’t want someone to come in three months later and be like, well, no one’s giving us a cookie, right? Or worse, you know, hey, why are we making decisions about content amplification and what isn’t amplified? And that goes against some notion I have of, of the freedom of expression. Right? And that. And it has to be acknowledged that some of the decisions that we make are business decisions, right? Twitter is a business and it exists not necessarily to make huge amounts of money, because otherwise we would have done that by now.

Alex: Right.

Matthew: But it does exist to fund this engineering organization and I’m telling my peers, like, if you like to work here with engineers of this caliber solve meaningful problems that definitely have user and financial business related impact, then you want to make these decisions in this way to make sure we fund ourselves and keep the product available again for the citizen journalism.

David: Yeah. You mentioned too that the health team is kind of like a spider team and that you sort of have interdependencies with a lot of other teams at Twitter. I’ve worked in teams like that too, and my experience in those teams that oftentimes you end up sort of. Occasionally you’re tasked with influencing a lot of different teams in the org to make it. You mentioned something like cleaning up tech debt. Right. And so occasionally you’re tasked with sort of this need to influence a lot of different teams in the org to make some sort of change that they’re not maybe necessarily excited about, that it doesn’t necessarily directly drive their goals forward. And one of the challenges that, you know, broadly, I think staff engineers face is sort of like, how do you align groups of people towards something like that? Especially sort of the not sexy problems. Right. Is that something you’ve encountered and how do you deal with sort of the conversations with outside teams or even within your own team of sort of like, look, this is the thing that we have to do, you know, and let’s figure out how we can make it happen and how we can all work together toward this sort of bigger, nebulous, messy thing.

Matthew: Yeah, that’s a really good call out. So if I can step back maybe to 2019, the team that I work on today is a component of House. It’s about, if you count myself, seven ish ICs. And we didn’t exist until December of 2019. And so what happened was folks were building product, they were duct taping things together. I don’t mean to be pejorative about the quality of the engineering. Right.

David: Sometimes I think every engineer listening to this does not take duct taping things together as a pejorative. It just is something that happens at various stages of growth.

Matthew: Okay. So we acknowledge that there’s sometimes business bets and stuff that make us optimize for velocity. And that’s part of the thing that one of the skills that we have, I mean, if they left me alone, I would make the most beautiful infrastructure ever. Just put a page up that says Twitter is down for maintenance for like a year.

David: Do you implement edits?

Matthew: Let’s talk about that later. Constant joke right around the office.

David: Evergreen. It’s perfect.

Matthew: The edits. There might be a couple of secrets around that or whether that’s actually hard these days. Or not. It was definitely hard early. It was definitely hard early because of database replication and indexing of tables made it super, super hard to go in and do random seeks and writes to the corpus of tweets. Of course, things aren’t stored that way anymore, so maybe an edit button is in your future.

David: Just keep asking directly.

Matthew: I’m sure he’d be so happy to hear that.

David: Perfect. Yeah, I’ll put that in the show notes. Ping jack directly. Done.

Matthew: Oh boy. If he finds out that for sure, then I would be shown the door. Yikes. Let’s not do that. We were talking about spider teams.

David: Yeah. And the challenge of getting different groups of people to collaborate on things that maybe don’t even further their roadmaps that much. And it’s largely about sort of getting people to do you a favor and clean up their code.

Matthew: Right. Well, I did something different. So I started to tell you a long story about growing a team where none had existed to own this sort of cross product nexus of health related treatments, warnings, interstitials, flags and sort of things. Just general purpose safety features. Well, it didn’t exist. So I wrote a vision document and sent it around and it said basically the fact that this is completely unowned or is in, it’s in that space, the cracks between team ownerships and it always falls through. It’s like owned by everybody, but owned by nobody. I said this is a massive business risk. We need to create a team to do this. And lo, the leadership gave us some headcount. So what we did with that headcount is we started to go into other people’s services and swashbuckle a little. We took some of the logic that really should be ours per charter out of their services, put it in libraries with some, I don’t know, then maybe not the best interfaces that exist. But there are interfaces where formerly there had just been intertwined growth of stuff which no engineer likes. Right. We factored stuff into our own code base, we’ve established interfaces, as I mentioned, we’ve cleaned up other people’s services at all layers. Right. Core services layer, composition layer, API layer. We now have touched maybe 15 services that we don’t own, responsible for serving nearly everything in the primary product serving stack of Twitter. Right. So that’s a kind of a. Not an answer to your influence question, but it might be. So I didn’t influence teams to clean up their own tech debt. I said the fact that this debt is unowned and doesn’t Track with Health’s product sort of vision and timeline means we need to own it for you and you will be our customer. And of course that goes back in the hiring for those particular ICs where you want to say not only is the mission fit essential and the fact that you won’t get pat on the head, we’re also going to clean up a bunch of folks legacy stuff. So I managed to find a few very, very excellent like minded folks who once they came in they said I’m ready for this challenge. They looked at this stuff and said that is really disgusting. We can go make it beautiful or at least less disgusting. We went and did it and it’s still an ongoing process. But the end vision is you’re going to make a change, make it in one place or a small number of places. Right. Not 15 services that all have randomly different deploy schedules and with mismatched versions of libraries running in production and. And of course they’re not independent. Right. So treatments adjusted at the core services layer will be munged again at the composition layer and will the APIs render them or not? And then what do the clients do? If I’ve got the same sort of business logic encoded in multiple different fields on the API struct, they’re going to shout because that’s not great. So my work will never be done.

Alex: I mean that’s a really interesting approach. Was that you said that you wrote a vision document. Was that sort of the. The start, you know and it was that something that you identified and were sort of self motivated to create and distribute.

Matthew: Yep, that was one of my greatest hits. Still gets hits mostly me showing it to new hires. Read this. There’s a lot of it is still true because it would be would be multiple years to really make. Well no one’s going to fund us to make the gleaming thing so we have to. For example forcing functions like the COVID crisis and the elections of 2020 in US were functions that caused us to make changes to some of those treatments that how they’re represented on the product. So what we would do is we would slide in under that work sort of a little bit of tech deck cleanup, a little bit of consolidation, a little bit of nicety, fewer places to touch. Put ourselves out of the business of making changes in 15 services and getting 15 different code reviews and waiting for 15 different deploys.

Alex: Nice. That’s awesome.

Matthew: Thanks.

Alex: So you mentioned that you’ve been at Twitter for 11 years now and you also mentioned that that might be a little bit different than Others. And I’m curious, to what degree do you, do you think about that and do you reflect on the road not taken and what sort of keeps you where you’re at?

Matthew: Yeah, I get this question a lot. It’s a good question. Certainly. When I was at Twitter originally it was a startup and some of those folks, we were about 120 total heads. When I joined, I remember because we had a party for the 140th joiner and if you get the joke, used to be the case that we limited the tweet length to 140. Now it’s a circle.

Alex: I remember, I remember. 140.

Matthew: All right.

Alex: Yeah.

Matthew: Well, the SMSing of tweets is not something we do as often as we used to. These days at any rate, I definitely encountered folks in a trajectory of putting chips down on the felt and moving every two, three or four years. Four would be sort of long in the tooth for someone who was sort of going breath first. Cover a bunch of industry bets. Now a lot of my peers early in that first batch at Twitter are telling me, hey, you’re leaving money on the table. And you know, that might be true. So. But about the end of my first sort of four years, I get the chance to sort of apply for staff. I told my manager that I would like to go for it and definitely rejected. So I think that might be true of folks that are listening, may resonate with that because I do think staff is a high bar. And I still tell folks I mentor inside Twitter that staff is actually kind of a high bar. So we have to make sure we craft the stuff that you’re going to show that’ll eventually make it into that packet. You know, pretty carefully. We’ve got to choose the. Be a little bit tactical about how we choose what we do to, you know, show that sort of 12 month track record that’s going to get you the win. And once you get that level, then you can sort of relax back into the autonomy that it affords and go attack the problems that are the right ones. You know, there’s sometimes a little bit of a divergence there. I’m not telling any secrets, right?

David: No, definitely not.

Matthew: But you asked me why I stay. Oh, definitely not. Do you want me to continue the story about why I stay at Twitter?

David: Yes, I do want to hear that. I think actually I want to introduce briefly. Yeah, I do want to hear it, but I want to bookmark because I think the idea of like preparing a promo packet and, and sort of the idea of like the difference between what it takes to get to staff and then what you can do once you’re there. You mentioned like the autonomy that it affords. I do want to revisit that. I think all of that is really, really sort of relevant to our conversation broadly. But I’m sorry to interrupt. Please continue with telling us sort of.

Matthew: Let’S go where I think the, you know the most me is right. You know, the story ends up with me getting old and having a bunch of kids. So if you.

David: And then your manager told you that you weren’t hitting senior staff. Right. That was the you told us earlier.

Matthew: Well, I’ll get back to that story. So you asked a little bit about what you do in a run up to a promotion case versus what you sort of do when you’ve checked that box and you can be autonomous as really what the latter asks you tell us what we should be doing. Right. Where we can improve. Well, anyway, so I recently had an experience where I mentored and I see that. I really, really appreciate up to staff. And we started talking about this in over a year ago. Right. I think it took about a year for that case to be heard, maybe a little under a year. But we gave it a long track record. And so we kept a doc, which we both worked on and we kept adding stuff to it and we chose to IC’s work diet. Not to the degree that I choose things right, but I encourage them to prioritize specific things not because they had the most business impact, but they had a property common to them. So one property was you would be working with someone on another team. A little bit of cross team exposure does, I think tend to help. Again, not a secret. Also, I chose them. I helped them choose their work, you know, nuggets because they were small enough that they could be sort of delivered in a certain time frame. A series could be shown like a little bit of a track record. And they would have, if you imagine overlapping dependencies with people on other teams. So you would really get around, you know, a cross section. Someone from revenue, someone from Enterprise, someone from, you know, core product serving.

David: What you’re describing sounds like a pattern that I’ve seen, but I think it’s interesting that it’s sort of different than the conventional idea, which is like a staff engineer leads one big project and then they’re ready for their promotion.

Matthew: Well, that is a way I think I would think that. Well, I thought about this ahead of time because I anticipated you might ask this. So we often think about, you know, Paradigms of staffness which sometimes try to classify, which I think is reasonable. From my observation, I see there are sort of two broad categories, depth first and breadth first. So my depth first staff sort of exemplar. I’ve seen a few of them who were very, very deep technical experts on a specific thing. Sometimes that thing is mission critical and sometimes that thing is one of those sort of overlooked, it should just work kinds of things. And that can be unfortunate. I remember a specific person who was thinking about advancing the senior staff and I was telling them we need to take this technology on a roadshow through the org. We need to meet people, potential customers on other teams, ask them what they need, build the things that they need, right? At least build a relationship with those people. Because if we’re, you know, separated by many layers of abstraction, you’re like, they’re not going to know you, right? And I’m not saying those people are specifically on the committee or not or those people are specifically going to give feedbacks that go into the packet or, you know, not. But the general I influenced by communication, I set vision, try to build consensus around it. Some folks subscribe to it. If they can get something out of it, great. That sort of paradigm, I think at the senior staff level that is pretty much all I see. I don’t see the depth first delivered like one huge project folks. I can see them get to staff. And I don’t want to say that Twitter’s promotion practices are not up to par. I just think there are headwinds to the depth first model. That’s an opinion. It’s probably based on the folks that I know, probably based on where I sit in the technical and org structure of, you know, places multifaceted as Twitter. So on the other hand, so I coach people like the Mapiloti school of, you know, staff plus engineering, which I do individual sessions of that at work all day. It’s the breadth first one, you know, each of these pieces of work under a common theme, each has a different dependency. Each had a specific measurable business impact. There’s a story to each one. A lot of times for us in health, the stories is easy because of the. I don’t know if you know this, but it’s an axiom on our end like more unhealthy behavior equals less user engagement, retention, growth. So it’s just drive down the bad stuff and it removes a depressor of growth that’s been around a long time and we don’t bother to measure it anymore. We just measure Bad stuff and say it’s on this face a good thing to drive it down.

David: Right? Interesting. The Matt Bellotti School of Staff Engineering. I really like that. I think that’s going to be the title of this episode. The question that I have next is going to be hard to answer succinctly because I think it’s not super realistic, but it’s maybe a useful starting point for people is like kind did you learn all of this? And especially are there any resources that you would point folks toward if they came to you and they’re like, hey, I want to learn what it means to be a staff engineer, you know, or to just be a high impact software engineer in my organization? Right. Are there books? Are there blogs? Are there like other people? Do you want a bunch of people pinging you directly? Like, where would you point people?

Matthew: Well, there are certainly a lot of books, blogs and other really useful stuff. I think probably our session here and the broader project that you guys are driving would be a useful resource for folks. And so thank you for doing it. But no, I’m sort of of the school really where if that’s what you want to learn from me, I’ll sit with you for as long as it takes to try to talk about it with you. You know, over time I never turn anybody away. Which is why I mentioned that it would be nice if our sort of centrally executed mentorship program would still be in operation. And I’m going to go make sure that it gets back up and running to the degree that I can. But it’s super valuable. I think people should have mentors and I think mentors should not, you know, prioritize anything else because there is a limited supply of them. You know, it wouldn’t be fair for me to say, oh, too busy, you’re stuck at senior forever. Right? Terrible. What if I lost a five year senior engineer because I was too busy to talk to them? And when I say talk, I really mean help you plan what goes in to that case for the next couple years. Think about tactically when you want to launch the case, right? Who do you want to talk to? Who do you want to ask for feedback from? How do you make the ask? Right? Make sure you provide an escape hatch for folks who feel like they don’t have bandwidth or signal to write for you. If you don’t provide that escape hatch, you’re going to get slapdash or maybe even bad feedback at best, unuseful. So there’s a few tactical things to it. And then I just, my Other problem is I didn’t write it down. So you ask if there’s books or blogs. Right. I feel like there should be. There are a lot I know. I feel like I should write one if it isn’t already a very well subscribed space. But nothing is better than you bring me your situation and I try to help with your specific situation. That is a personal opinion that might lead to a lot of time spent for possibly low benefit. I acknowledge that. Right. But it is fulfilling to me because I come from an environment where one on one advising was a very, very integral, sort of normal part of the experience. And I carry that with me. I liked doing that. I thought I was going to be a university professor because I like doing that so much, but I’m not. So I get to scratch the itch by helping people grow and it actually builds that relationship. So now they’re off in other corners of the org and I can make a suggestion to them and it’ll be considered seriously. And I like that. I appreciate that. And also they stick around. Right. So if I can stretch someone’s career at Twitter from five years to eight years because they made staff and they’re still learning, challenged, growing, just doing whatever the right thing is and hopping from project to project whenever that’s necessary, that makes me feel good. Anyway, I want the Twitter where I want to work to have those people doing those things there. So it’s entirely self serving. Yeah.

Alex: That’s an incredibly thoughtful approach. And if you’ve got a book to write, I’d read it so well, you.

Matthew: Complimented me already twice today, Alex, and that’s really generous. I appreciate that. You know, we’re going to have to.

Alex: Bring you back on to tell us the story of your time at Twitter, but I don’t think we have enough time today. And the last question we like to ask people, and you already touched on this, is, you know, how much time do you spend coding nowadays?

Matthew: Waxes and wanes. But guess what? I’m not that good at it anymore. Right. You know, I’m actually writing some code on a tiger team right now because there was a need and a tiger team was organized of all staff plus. So I’m all in there writing code. Not like I’m, you know, yelling at my intellij why the unit test will, you know, break. So I don’t have the, you know, at senior where your peak of codop or you’d be turning around several diffs in a day. And you’ll see, you’ll see a null Pointer, exception of some kind. And you say, oh, I know there’s a gap in this mocking here. I’ll know where it is. Plug those gaps, you’ll be able to execute very quickly. But me, no. Right. No manager or high level leader should say, put Matt on some code. Right. Because it’s going to take three months, you know, because I have a lot of things to do. And so when I do code, it is usually stuff that’s not on the critical path. It’s usually something that makes things better behind the scenes. Efficiency, cleaning up stuff, that kind of thing. And it’s purely as an avocation. This is really not what I should be spending my day to day on. I know that. But I still can’t get the bug out. I mean we essentially, this is why we joined this. We like to fix broken stuff. I have to be at peace. And I still struggle with this. I’ve been at senior staff for five years now and I still struggle with, hey, the way that I make stuff better and solve problems is by teaching someone else how to do it so they can just go off to the races. I teach everybody that I work with, everything that I learned along the way. Then it’ll be the best engineering org ever and I can relax.

Alex: Nice. Well, thank you so much for coming on the podcast.

Matthew: Well, thanks a lot. It was a real pleasure to meet both of you, Alex and Dave. And I really appreciate you driving this project. I think it’s going to be fun. I will be a subscriber. I’m a noted consumer of podcasts and this will be in rotation, so let me know.

David: Matthew, it was great to have you on and Alex is right. I’m sorry for cutting off your story about your time at Twitter. We’re going to circle back to that one day. I can’t wait.

Matthew: That sounds fun. I think. So I planted the seed to earn myself a return visit. That’s great. So I’m looking forward to it. Thank you guys. Be well.

David: That’s it. Thanks so much for listening to staffinch. If you enjoyed today’s show, please consider adding a review on itunes, Spotify or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.

Alex: You can find the notes from today’s episode at our website podcast.staffenge.com the website also has our contact info. Please don’t be shy.