Leading a Team of Internal and Open Source Software Engineers

A conversation with Madleina Scheidegger, Engineering Manager, Google

Recently Sarah Drasner introduced me to Madleina Scheidegger, who leads the Angular team at Google. I’m so glad she did. I appreciate her perspective on leadership. Our conversation covered the key to managing a team of internal and open source software engineers, her style and the need for leaders to stay flexible.

This interview has been lightly edited for length and clarity.

I'm so happy to have you here. Can you give a quick introduction?

I'm Madleina Scheidegger. I'm currently the Engineering Manager for Angular at Google. I've been in this role for about a year. I've been at Google for more than 15 years now, so it's been quite a journey through that to get there.

Oh wow. That’s a good amount of time. Did you start at Google?

I started my career at Google. I'm one of those who goes against the current trend of often changing companies. There are moments where I wish I had more exposure to other companies, but I've also been on a lot of different teams in different countries and continents, so I've gotten exposure that way instead. Sometimes I'm a little risk-averse. I like what I know, so it's been easier to stay in some ways than to make a change.

It can be difficult to find the right environment, where you can continue to grow and learn, and also give back. It seems like you found that at Google.

I think so. Some teams and some of my time there have been better than others. I've also learned over the years how to better choose my environment, even within a company, because anytime you're more than probably 20, 30 people, or even a 100 people, you end up very quickly getting to the point where different teams are different and different people have different environments. The hard thing is finding the one that fits for you and finding the people that fit you. I find that as important as the project itself. Is just the fit with the people and the culture around you, in that regard.

You talked about being better at picking or finding the right environments. Does that mean you've been able to have some say in what you want to do and the team you want to be on?

Yeah, absolutely. Google has a relatively easy way of transferring. As long as you stay within your same job role, you don't have to do interviews to transfer. It's more a matter of talking to the team saying, "Hey, I'm interested. What is available? What position? What does it entail?" Have a mutual conversation if there's a fit or not. It makes it much easier to do internal mobility for that reason. That's how I've been able to pick and choose to some degree over my time where to go to. That's what I've done. That's how I got to this job as well.

It sounds like you can change and remake your job. So even though you’ve been at Google for 15 years, you're not doing the same thing at all, those experiences are probably so different.

One of the nice things about being at Google is having that ability to move and change. As you grow, you also want to take on new challenges. At least for me, it's been good to take that next step of trying something new, trying a little something scary where you’re really pushing your skills in a familiar environment. Once you've done that, it might be nice to maybe switch to something else where you're now taking on maybe half a step up instead of a full step-up in terms of challenges in a new environment with new people. It's been good to sort of pick and choose, even within the team. There was one team I stayed with for eight years, but what I started with versus what I ended with was very different.

On that team, I went from being an individual contributor to being a manager. That was quite a journey. Of becoming a tech lead, then becoming a bigger tech lead, and then becoming a manager. I've enjoyed being able to find those challenges and be supported to be able to push myself into that next step of taking on more. Evolving the career and the direction I wanted to take it, even if it's not always been where I thought I would be, at some point in time. I'm not a person who has a five-year plan. I know a lot of people do, but I've never been that person with a five-year plan.

I don't have one either. How did this role come about?

About a year ago, I was looking for a new challenge. I was on my previous team for about two or three years. I've managed to tick a lot of the boxes I wanted to with that job. I was looking for a new change. A month or two before I started thinking about this, I got a new boss, Jules Kremer, who used to lead the Angular team. As she was ramping up, she was asking a lot of questions. I got to know her very well, and I got to know her previous team. It really intrigued me. I knew they were looking for a new manager for the Angular team.

I asked her about it. "I know this is kind of a weird question to ask your boss, but I'm thinking of a change. I'm thinking that your previous team might be interesting." So in some ways, it was through her that I ended up in this role, and I got to know about it. I got fascinated by many aspects of the role. I knew that it would give me a new way to grow and grow further and open that door to the next set of challenges and skills to learn. A lot of times it's your informal network, right, that ends up helping you find the right role, right? As much as we have the formal posting board, half of the way that you move around is you talk to a person, you hear that there's something in that team.

Someone comes to you and says, "Hey, we've worked in the past, you want to work together or not?" A lot of this is always that informal network. Fit is so important. What I'm interested in is what are the people you work with? How do you communicate with each other? What's the culture? What's the support system? How does the team operate? How does the organization operate? Are there conflicts? How are they resolved? That's hard to pick up from a job posting. That's why the informal network is very important for me because you get to know and talk to someone and get to know those details of a job before you take it on. You get to understand what you're getting into, in some way — in both good and bad ways.

Did you end up having to formally interview for this job or was it more like a conversation?

It was more of a conversation. We did a lot of fit calls. I ended up talking to the manager, manager’s manager, and a couple of folks on the team. For me to get to know them, for them to get to know me, and make sure that there is a mutual fit in this regard. In that sense, there were interviews, but there weren't formal interviews where I was being scored on my answers. It’s still important that you do those calls. I don't think I would ever take on a job where I didn't talk to more than just the hiring manager. I would also talk to some of the folks on the team to get a sense of what their questions are. What are they looking for in a person coming in with more leadership? That tells you a lot about the challenges you might be facing as you come in is what's on their mind.

Such an important point. We have to ask what's going on for the team? What are they thinking about? What do they think are the challenges? What's keeping them up at night? It tells us a lot about what’s going on.

It tells you where they need the help. Are these areas that I am strong in helping, or are these areas that are outside of my expertise and someone else might be a better fit?

It's so important too, as a leader, when we're coming in to make sure that we're doing that. If we want to build a partnership with the team, rather than just giving orders. I think most of us know giving orders is just not very successful and it's not a fun experience for the people receiving the orders.

I've had more success in, I don't even know if there's a term for it or not, but I feel like almost a soft touch in some ways where it's a lot more about nudge a little here and nudge a little there. Talk to that person, coach here, or coach there rather than, "Here is what we're going to do" because while I can mandate, it won't stick. Instead, if I work with folks, if I start getting them to buy into the vision, and give them the skills, I have a more long-term success than, "oh, it just happens. you wrote the paper, but did you believe what you wrote? Maybe not. What is going to happen next time you run into this?" It is so much more behind the scenes just nudging people, talking to people, all that part of it.

Your style sounds people-focused and collaborative. I have a similar kind of style, I'm not interested in power and telling you what to do. That just holds no interest for me. Sounds like for you too. How big is the team?

It's about 20 people. Let me preface this, team is always a hard thing to define because 20 people report to me. If you ask how big is the Angular team, you probably would consider other folks and people who don’t report to me as part of the team as well. Some of it is cross-functional partners at Google like a DevRel team that we work with. We have tech writers we work with, program managers, project managers, etc. If I think of it as like the Angular team and how we run holistically, these are all part of it.

We also have a lot of external contributors, and some of them are closer to the team than others because some of them have contributed for so many years and have critical knowledge about parts of our system. If you think about the Angular team overall, do they count as well or not? They probably do, so this is where the term team always becomes so fuzzy like the different contexts of different answers in terms of what ends up counting or not counting in that regard. But it’s also one of the fun things.

My husband's an infrastructure lead and I told him I was interviewing you. He was like, "oh, I want to know this and this and this." Some of my questions, I have to be honest, came from him.

I love it.

One of the things we talked about was having both internal and external folks to consider. How do you figure out a strategy that covers both of those audiences?

I was thinking about that question when I saw it because it's one we get asked a lot. I'm changing my default answer, because what I used to say is, "well, we're lucky that our problem sets are mostly the same." I realize that's the wrong way to look at it. That has to be our strategies that our problem set has to overlap largely. We have one code base and we have one what we call "Source of Truth," which serves the same for internal and external. If you don’t do this, what will happen is over time, you fork, and you have two codebases, and now you have two products.

I want to make sure the largest chunk of our strategy is the same for both. Yes, there will be parts that are different because we have to integrate with tooling internally that doesn't exist externally. There are other tools externally that we need to use instead. At the same time, the biggest thing is that we have to think of it as a holistic product. It is still very helpful to me that whenever we talk to our customers internally, when we talk to our customers externally, the problem set that we get back in terms of their biggest challenges is mostly duplicative. We are in that position where both our strategy has been working out that way, and we're mostly getting the same feedback. Here's the part that's hard to use about Angular. That makes it easier for us to set that strategy because then it very naturally follows that most of it are the same for both. I used to say luckily, but really it has to be deliberate.

Being deliberate and thinking holistically, strikes me that it makes things a little bit easier. You don't necessarily have to think about what projects to work on the internal audience versus the external audience because there's so much overlap there.

It's not like all of our work is that way, but I would say the majority of our work is that way. That's the part that has been critical in these projects. I've been talking with people on other projects at Google with an open-source component. What I'm finding is that some projects have the same strategy. You have that one source of truth because that's the way you can keep it together. Otherwise, you're essentially staffing up two teams that have the same name and happen to have some overlap, but not enough. It is the way to think about having that commonality, and that's going to have to continue striving towards our future, as we think about new projects. I know that every time we do a design it's the first question is how does it work with both? How do we not split? We don't always have to ask explicitly, but it's something that is in the back of my mind that we cannot do that. That's the thing we cannot get to.

It strikes me that when you were talking earlier about "what is the Angular team?”, it's a way also that you're thinking about who the stakeholders are and how do we keep them all aligned and moving together.

At the end of the day, developers are developers. A lot of times the challenges that you have are the same no matter what you're surrounded with. Yes, we have different tooling that we have to integrate with, but a lot of our challenges are “this feature doesn't work well”. That's the same, regardless if you're working internally or externally.

For example, one of our biggest [requested] features is typed forms. The fact that not having typing on forms is a pain point for you, has nothing to do with where you work and what environment you're in. It's less about the specific product, it’s more about is the tool actually helping you, or is the framework giving you guidance to write a better product? That's the same, no matter where you are, no matter what you do. The challenges facing developers are the same, at the heart of it is often the same, no matter where they are and what they're working on. Some of them will be a little different if you're scaling as you have more people working together, or as you trying to build a more complex product, taking type forms as an example, if you're working at scale, it's good to make sure everybody does the right thing.Regardless of where you are in that spectrum, at the heart of it is still the same thing. Having types helps you make sure you don't make mistakes.

 That's the other thing I think we often underestimate because we're so caught up with these differences, we forget the similarities of it and how much of it is actually the same between the two sets of developers. We just want to build products at the end of the day.

Did this holistic approach start from inception, or was that a conscious turn you all made?

I don't know about inception because Angular has been around for more than 10 to 11 years at this point. It's hard to know from there. I've had some good conversations with the people Igor and Miško who created Angular. I didn't overlap very long with Miško who left just about when I started, I've had more chances to overlap with Igor and talk with him for a while. I do know it was a very deliberate strategy even before I joined.

So Jules, who I was mentioning before, used to be an engineering lead, was striving towards this as well. It's been around for longer than me. It's useful that the team has already been thinking about, but I don't know if it's been like seven years or 10 years or something along those lines. But it's been for a while that the team has been thinking about that, and has been pursuing that strategy of doing both, of trying to focus in on that and think of it in that regard. It's taught me a lot.

How has it changed the way you think about things?

I didn't realize how important it is to keep it the same. I knew coming in that this is an important mantra and we have to keep that mantra, but over the year, it's become more internalized. If I am ever faced with the situation again, now it's a much more natural tool I will reach for and be like, of course, what we should do is keep it the same, because now it's been internalized.

I know how it works, and why it's so successful as a strategy. That's what I mean with change is sometimes you know something intellectually, but you have to go through it for it to become much more subconscious in your mind. We don't even explicitly ask ourselves anymore, is this going to split the product around it? Just sort of, so implicitly in a lot of the discussions we have, but it takes a while for it to become implicit, and implicit for everybody on the team including myself.

Ah, like an operating system. This is just the way we think about this. We think about this as one problem set, really one audience. It's a really interesting approach to moving a product forward but also makes the leadership and the management piece of it easier too, because you don't have these competing factions, competing people who are competing for attention or priority.

We always have that in the sense that everybody wants their favorite feature to be first, of course. No matter what audience you have, you always have the people having a different opinion, but it's the usual problem that you have with priorities of everybody has their favorite thing that they want to have worked on first versus I have two different sets of audiences that have priority, how do I balance the two of them? There’s always the pet feature.

How do you all decide what it's next to work on? What's that decision-making process like?

That's a very good question. It's both bottoms-up and top-down. We have a very tactical daily execution or weekly execution model, where we make a lot of micro decisions. That's sort of them bubbling up and I'll talk about that a little bit more. I used to work more on the consumer side and there was a term: North Star vision. I think it's a really useful concept and setting that same North Star in terms of here's what our main priorities are and here's what we do, in order to inform what we do. Then it comes together in some ways. All of this is informed by what we know from our users.

We have a great DevRel team that keeps us up to date on what we know externally. We hear from our internal customers, we have GitHub issues, and we know what's been upvoted. In some ways, we know what we need to change from that, from all the listening we've done over the years, and it's been continually coming in. We know what are most of the major pain points at this point. It's not a matter of understanding which ones there are. The bigger challenge for us has been figuring out which one to tackle and in which order. This is where I think something like the strategy from the North Star comes in where you say, "What are the things we're going to focus on this year?" And taking two or three directions and also explicitly saying here, "Yes, we could, but we have to make some choices."

Then very tactically, this is my style of not being a top-down leader. I actually defer a lot to my tech leads and say "You know your domain, you know your area, you see the issues every day, you know what you hear from your customers every day. You tell me what you want to work on." We have a conversation about it. The tech leads talk to each other about it too. We have one spreadsheet where every sub-team has their priorities and everybody can see what their top priorities are.

We have a standing meeting where if someone is like, "Actually, you know that thing I need over here," or "What about this?" We can sort of resolve them as a group, but we also try and make sure we give autonomy to each of the sub-teams who know their domain very well to be able to make those decisions and be able to set their directions in many ways.

I'm not a top-down, setting everything in stone, kind of direct leader. I want to have the people who are immersed in their role day in, day out, tell me what makes sense from their point of view. 

You have quite a collaborative style. Was Jules’ style pretty similar?

I think so from what I've seen of her. My philosophy on this is that I could spend all of my time knowing each of these areas well enough to send the roadmap on it, but then I wouldn't have the time to do things that I more uniquely should be doing, which is going upward and outwards. I have to make a choice about where I'm spending my time. I can set the direction for all of these teams, but other people can do that too. I'm not uniquely qualified for it. I'd much rather add more value to the team by talking to other teams outside, making partnerships,  making sure our leadership is happy, shielding them from anything there, and finding more resourcing.

Whether or not that is finding other people to collaborate, finding more staffing for our team, whatever it else might be. That's something I can't have my tech leads do, but they can set the direction for their teams. The way I look at it is…what can you uniquely do? That's been one of my mantras. I can't send people to go talk to finance. That's not the right call. That's the thing I can uniquely do, but they can do other things. That's where a lot of it comes from, where I could, but then what are we not doing as a team? I could (make the decisions) but I just don't think it's the best use of my time. I think that's why it comes across as collaborative, but it's just  obvious to me. It never occurred to me to do it differently.

I've worked with leaders who are more directive and who have had a hard time letting go of the work. I do think some people struggle with the difference between managing and leading. They’re not the same thing.

You can be a lead without managing and you can be a manager without doing a lot of leadership.

Yes!

A large part of it is how do you think about your job and what you want to do? Wherever you are in your life might be right now to make that choice and say, you know what, I'm mostly just focusing on managing, because I don't have the time, the capacity, and the mental space to be doing a lot of leading at the moment. I'm not going to say that's the wrong choice. Sometimes that's the right choice given the circumstances. The important thing is you have to make a deliberate choice.

Right, and what's going on in the situation.

I don't want to imply that there's only one style or anything that my way is the only correct way or anything along those lines. It has to be an actual choice, not just because it happens to be your actions and you don't realize the choice you're making through your actions.

100% agree. On another note, the team just got below a hundred pull requests and you all started at 650. That seems like a pretty huge accomplishment. What were some of like the obstacles and the way you thought about that challenge?

I'll give credit to my team for doing most of this work. They've been doing it for a while. It's been more keeping them on the rail. The number one thing is you need to have accountability and responsibility. We have a weekly, what we call caretaker routine, where someone is in charge of looking at the open PRs and dealing with them. There are the ones who just came in that are "Okay, clearly something needs to be done," but it's easy to say to the ones that, "well, the one from three months ago, if there was no action on it, do I really need to do anything or not about it?"

That's where the responsibility and accountability need to come in. What I'm grateful for is that there are people on my team who ended up deciding, "You know what, I hate this number. I'm going to do something about it." They just started systematically working through the old ones and say, "I'm just not going to just ignore it. I'm going to spend the time beyond what normally is my expectation for doing this and take a look at it." Some of it was just that the author never responded to the last comments we had on it. If it's over three months old, maybe we'll just close it at that point in time, because clearly, they're not coming back to it. One of the things to note is we develop in GitHub, but we need to bring it into Google3. Our code base is called Google3. What we need to do is make sure that when we bring that in, it doesn't break anything internally.

Part of what might happen is, “it's been a while since we ran the test, we just need to rerun them and make sure it's still nothing is broken” or something was broken “Let me look at what actually broke, rerun it if it's been too long." It really was just then a couple of people started, and then others were like, "Oh, I should do that too." You just need a couple of people to start doing it, but it's not just looking at what you technically need to do, but also look at that back on and go like, "You know what if I just spend a little bit of time looking at five more this week than I would otherwise I can start making a dent."

A lot of this is also just persistence. This isn't going to be overnight. This isn't going to be immediate and more saying, "Okay, we're just going to try and close five extra a week." Sometimes it was more, sometimes it was less but just continued at it. This is where I'm thinking there's no magic to this. It's just hard work and sticking with it.

It seems like there was a bit of contagion. It wasn't like we want to get to this goal. It just started to proliferate, and the culture around that caretaker role and pull request shifted because somebody said, "I'm going to go deeper." and then someone said, "I'm going to go deeper." "Well, I'm going to go deeper."

That's pretty much what happened. Once one of the two major sub-teams started doing this, the other one similarly around the same time, had someone stepping up. It really is that you need the one person to start that. Then ideally you have the second person jumping on and then it just tends to snowball from there. Most of what I've done is just encourage, but I'm glad I have that culture on the team where they feel empowered to say, "You know what, I see a problem, I'm going to go fix it." Instead of feeling like they need permission, it’s "This is a problem I could do something about, I'm just going to go start doing something about it."

Yeah, I love that.

At the end of the day, it's a lot of hard work and it's a lot of taking accountability and sharing that load. I think the other thing they started doing is sharing, "Oh, we got it down to like 500," and you start celebrating every little milestone that you do every 50. That ended up encouraging the team too, it's like, "Oh, we managed this many. We can do more." Being able to always celebrate the small wins and the small steps and not just at the end. We took a step in the right direction, and celebrated, took another step, and took another few steps, celebrating and acknowledging that you're making a difference and you're getting in the right direction.

I understand you also reduced your outstanding issues from like 2,900ish to 1300. Was it similar or is it a different process?

I think it's somewhat similar to the difference there being, we don't actually have anyone responsible in the same sense that the caretakers are. Again it's a lot of hard work and persistence. This is where sharing the load will come in, which is another thing that I think is important in these cases, where someone would just set up an hour and say, "You know what, I'm just going to spend another hour looking through these a week." By setting it up and saying, "Hey, anyone else want to join in?" It turned out that by just doing that, you have another three people coming in to do it. Everybody would just work on their own a little bit by closing and looking at them and figuring out what to do about them.

It's that one person, in this case, more setting aside the time, rather than going above and beyond, but also having a forum. The difference with the issues is that some are easy to close. Some of them are also like, "We could do that, are we actually really going to do it or not?" As with any other product, we look at every single bug we have, but where it became important as well as to have that forum with other folks: :where is it on that line of are we going to get to it or not, does it make sense enough”? Does it make sense with the direction you're trying to evolve the product? When they're making a change of introducing a library or using a library more:  Is that something we want in Angular overall or not? It's hard to make those decisions in isolation.

This is where the community aspect comes in. Being there and supporting each other. We have a standing meeting where people can also bring and say, "Hey, what do you think about this one? What do you think about that one?" Discussing it and being able to talk about it. Once you decide on one of them it often ends up having like falls out another five of them that are similar. It’s really important to make sure that people have a place to support each other and make a collective decision. A lot of times it's hard to decide in isolation, but having other people validate your decision helps you to make that decision and make a decision about issues. I think that's the other reason why they linger.

I think it's really interesting too because I think there could be a stereotype or belief that you need a tiny team to make a decision, but sometimes the collective can actually help make a decision, in this case, so much better.

Sometimes you need one, sometimes you need the other, but yeah.

It's like knowing when?

I think we've probably done the easy ones now. Now we're faced with the much harder questions of the ones where we like, "Well, this might be a controversial decision" or ones where it's like," Well, it really is kind of a serious bug, but are we really going to get to it or not?" So I think the next 500 or so issues are going to be much harder to close than the last thousand of them have been.

What advice might you give to others about leading a team or a situation like this, or what advice would you give pre-Angular team you?

I would definitely say take the job. It was one of the better decisions I made.

One of the biggest keys is being flexible. There is no one answer for any one situation. The most important thing is to be able to not be preset with a path before you know whether or not it's the right path. If you go into it with a preset idea you're going to tie yourself into knots. You have to be flexible and adjust as you go along. Don't go in with too much of an assumption. Be open to changing your path and changing your mind as you go along.

I think a lot of leadership is being adaptive to what is changing, what you're finding is actually happening, and you try something that is working great, continue doing. If it isn't, try something else, don't continue. And instead of adjusting and that constantly like meandering and finding the path in some ways, in my mind.

If this piece resonated with you, please let me know and give the heart button below a tap.