Allison McMillan — Leading Through Multiple Reorgs

Reorgs are tricky parts of organizational life. Allison McMillan, a Fractional VP of Engineering is an experienced leader who has worked at companies like GitHub, Forem and General Assembly. Throughout her career she’s been through many reorgs. We talked about what it’s like to lead during a time of high organizational change, building trust with new teams and how to plan during constant change. 

We know each other from the Ruby community. For those who don’t know you, can you share some background about yourself?

I'm a career switcher. I have a political science and Near East studies degree. Very, very useful in the technical world. I started my professional life in the nonprofit world and pretty early on I was the managing director of a nonprofit, which was sort of like a COO role. I learned a ton about management and leadership through that role. Then I taught myself how to code before boot camps were really a thing. I was a RubyConf scholar back in the day, and I did a lightning talk at my first conference, and that is actually how I got my first job in tech. So that's how I transitioned into tech.

Since then I've had a number of IC roles and management roles. I went back into more formal engineering leadership at GitHub and held a number of roles at that company. I’ve also been a head of engineering, VP of engineering at two smaller startups. Today I do engineering leadership consulting, helping individuals and teams sort of tackle the problems that they face in the situations that they want to talk through in their day-to-day work.

There was a point when you were at GitHub where you reorged every three to six months. How did that impact your own career progression? 

It was really challenging for a number of reasons. I was frustrated at the time that it was happening to me, but now that I've sort of been on the other side, I also understand it better. So I would be reorged, I would be under somebody new. It is really hard to put someone up for promotion and make a really strong case for them when you don't know them super well. 

Maybe it was just before a performance review or just after, but we all know, performance reviews, there are limited questions, there's limited context, right? It’'s almost never your direct manager who's making that decision about promotions. It's somebody above and beyond that. So I get it, right? As somebody who's also been on the other side of it, when somebody's been reorged under me and looking for a promotion, it is sort of like, well, I don't know how this person was managed previously.

I know what they've written down, but I don't know, it's hard for me to know exactly how they operate. If I get asked questions, it's hard for me to really have a full story to be able to push for this person to get promoted. So that was one piece. It definitely delayed promotions, because by the time whoever I was reporting to was like, oh, yeah, okay, now I feel like I know you're ready, I've seen how you operate, et cetera, I would frequently get reorged again. I think that had two impacts.

I know a lot of people that say that titles don't matter. But I think that titles do matter, especially for certain groups of individuals. And especially at larger companies, titles frequently determine who's in the room or who's invited into the room and who's not in the room. So that was tough. 

The second impact (of frequent reorgs) was that I put a ton of pressure on myself. There's this sense of being a little bit under a microscope. And because my manager had switched so frequently, I wanted everything to be perfect. I didn't want there to be anything that could mess up my chances. It's one thing if you're doing that for a quarter or even two quarters, but to do that for an extended period of time, to feel like you have to be perfect really takes a lot of energy to do that. 

Titles do matter, especially for certain groups of people. So I love that you brought that up, because it does matter, and I want other leaders to hear, yes, those titles absolutely matter. Maybe they don't matter for you, and maybe we would not like them to matter, but they matter.

Yeah, yeah, right. It's the kind of thing where I would have a larger scope of responsibility, but still have the same title, and then would not be invited into rooms or into meetings where all of my peers were. Then I was also playing catch up, which again, as I was putting a lot of pressure on myself to be perfect in whatever role, it's harder to do that when you're not in the meetings that you're supposed to be or you're not sort of thought about because you have a different title. It compounds and you spend more energy on even just being like, oh, did that, seeing someone's calendar and being like, oh, what was that meeting about? Now I have to go and follow up and ask about that meeting and make sure that if it happens again, I'm invited to the meeting and touch base with the right people. It's like eight more steps because of a title.

It makes it harder for you to do your job. Your experience is not uncommon. I'm hearing right now, people who are like, I'm acting in this role, but I don't have the title quite yet because we're having lots of reorgs and organizational stuff that's going on, and when is the title promotion cycle happening and all of that? So it's super relevant to what's happening today. 

I also want to go back to feeling like with constantly getting new bosses you have to prove yourself very fast. You feel like you have to be perfect. 

It's hard. I think as you get more scope of responsibility, you have to be able to take chances. You have to be able to make riskier decisions. You have to be able to make decisions that not everyone's going to agree with because you're using your experience and expertise and what you know about that area, what you think is best for that area in order to do so. And it might take a month, two months, three months for all of that to shake out, especially when the changes or decisions are more difficult. And when you're in that promotion cycle, it's more challenging to make those riskier decisions that you are maybe 95% sure will pan out, but also might not pan out for a few months. And during those few months where it's a little rocky or it's a little shaky or you're going through it, that might be when the promotion cycle comes up and then you sort of miss that because you're going through a time that you anticipated being more challenging.

That's so good, so rich. When the reorgs happened, what kind of role were you in? 

I also see reorgs as an opportunity. So each reorg, I gained more scope. I started as an engineering manager. The levels at the company have changed since but I'll talk about the titles where I was at. I was an engineering manager with one team, and then there was a reorg, and I had two teams then under me, and then there were a lot of reorgs, so I'm not going to remember all of them. Then I had the same two teams, but with a different department and with a different set of peers.

Then there was another reorg, and I was running a smaller department, and then another one and I was co-leading a larger department, and then another one and I was leading a larger department. So lots of differences. My title did sort of change through there from engineering manager to senior engineering manager to director of engineering, but again, not always when the scope of responsibility changed frequently. I would say not when the scope of responsibility changed, but that was sort of the progression. One team, two teams, smaller department, large department.

Yeah, that's a lot of change. It sounds to me like you were moved to different teams during that time that you had not worked with before. Were you leading teams you had not worked with before?

Frequently the folks who reported directly to me moved with me, but not always. I had a team that was disbanded because we decided not to spend as much energy and effort on the product. That was interesting because I had mostly new folks reporting to me. I was also making sure that everybody who had previously reported to me landed somewhere that they were happy with and that they had their next steps. Almost always my manager changed, some composition of the folks who reported to me changed, and my peer group always changed. 

Even if there were some things that were stable during that time of frequent change, there was a lot of swirliness and some chaos happening at the same time.

How did you build trust with a new team as a new leader? How was that? Especially because if you're changing a lot, that might be changing after a few months.

After a number of reorgs, one of the things that got more difficult was convincing folks that it was worth building trust with me. There was a sentiment that it was sort of like, cool, you're my seventh skip level or fifth skip level in the last year. People didn't want to get as invested in the relationship, which I understand. 

My first couple of reorgs, I almost always would bring the team together, bring the leadership together, and sort of be like, okay, what do we have in common? What's our department's mission and vision and values? After a while, I figured out ways to do it that felt still meaningful for the department, but lighter touch for folks. What I learned was that the leadership level above me felt like that was really important, but everybody reporting to me did not. It just created more, it destabilized things further because they couldn't do business as usual because they were being forced to create this new mission, vision, have this conversation, and they didn't know if it was going to matter three months down the road sort of thing. 

So a piece about trust is also just after a little while, convincing people that it was worthwhile. But for me, those 1:1s were key. Even if they're sort of like small group conversations, I like to ask a lot of questions. Things like, what are they most concerned? Are they concerned at all about the reorg? There are people that are like, look, I don't care. Can I just work on the ticket that I'm working on? Does anything change for me? And if it's like, no, oh, X, Y and Z might change, then they're like, cool. If it's going to change, let me know. 

Other people, it matters a lot. So I ask, how are you feeling about this? What are you concerned about? What do they hope stays the same? What are you worried will stay the same? So just asking a lot of questions. For me, also, a lot of the way that I build trust is by honestly doing the things that I say that I'm going to do.

I think people have a lot of experience with leaders saying that they're going to do a thing and then not doing that. That really hurts trust. I found that a really easy way for me to provide some real reassurances was to a) do the things that I say I'm going to do, and b) be really transparent about what I agree with or what's also on my radar, but that I will not be tackling immediately. So making sure that somebody feels heard, but also letting them know, I agree with this and I think this is a thing that we should continue talking about.

It is also not going to be a thing that I'm going to get to in my first 30 days, in my next 30 days as we're settling in post reorg and figuring out what that looks like. But I was always like, but I'm going to write it down. We're going to revisit it. I keep notes at every skip level to make sure to bring it up so people know it's not forgotten. It’s about being really clear about, hey, yes, this, but not now, so that people aren't expecting it. Again, it's just following up on the things that you say you're going to do and doing those things.

What was it like as a leader to plan in that environment where things change so fast?

It was so hard. It was incredibly difficult. I think what's interesting is that frequently the overarching goals didn't change. So one thing that I'll say about during this time of reorgs is that there was a lot of new leadership coming in. Now as having been a leader, you walk into a situation and you're like, ah, this is working okay, but I think it would work better if we did X, Y, and Z, right? If these departments looked this way, or if we had this sort of composition, or these teams should be closer together because they have a lot of dependencies and work really closely together. So we should sit them closer together in the org, which is great. When you have a lot of leaders coming in within a short time period and they all want to see the world in the way that they want to see it, it leads to a lot of moving around.

Now, it didn't lead to a lot of company-wide changing priorities. Again, once or twice, there was something that was deprioritized or a team that disbanded, or maybe a team that was working on two things. We shifted their focus to sunset one thing or to de-prioritize one thing and re-prioritize or prioritize something else more. 

What I learned is to have a lot of the planning happen based on product area and based on product focus. Then you can stitch those together as a department and you can create different ways of thos product lines in the same department, working together, solving common problems, figuring out what that looks like, even if sort of the day-to-day around the product success or the metric that we were looking at wasn't changing.

That's great. It sounds like the priorities were mostly set.

Thinking about it a little bit more, the most challenging thing related to planning was that there are some pieces of engineering work that take longer to advocate for, or they require a different kind of argument, a different approach. So sometimes those things would be prioritized based on a continued relationship, continued conversations, continued IC is bringing stuff up to me and me bringing it up with the manager, those with my manager, those sorts of things. Those were the kind of things that sometimes had to be almost reargued from scratch when there was a reorg, because then if I was reporting to somebody new, they didn't have all that context. They also frequently heard those arguments differently.

I had advocate to a new manager of mine why we were spending time, energy, and resources on X project when it had sort of already been talked about, discussed, et cetera, et cetera. But it had to be rehashed, rediscussed. Sometimes those were successful and sometimes they weren't successful. When they weren't successful, that felt very frustrating for IC is because they spent, it was often something that they cared deeply about that they really wanted to prioritize, that it took time and patience to get prioritized. I was like, I'm really sorry, we are deprioritizing this again but I'm going to continue talking about it and try to get it reprioritized.

That's such a great behind the scene about the influence we need and how it changes with reorgs. What did you find hardest about leading through a reorg?

Oh my God, everything. (laughs) I think the hardest thing about leading through a reorg is that there are so many parts and pieces to keep track of and to tackle all at once. Everyone wants everything to be settled very quickly, myself included. I want everything to be settled very quickly as well, which means that you often have two weeks, let's say, to do all the things. I have a new peer group, I need to touch base with my new peer group. And your whole calendar changes. It's like, how does this peer group communicate? How many people in this peer group are new? How many people are established? Am I the only one coming in? Is the entire composition changed? Do people do 1:1s with their peer group? What's the culture there? 

There's also new people reporting to me. So again, building that trust, building the people who have formerly reported to me, so reassuring them like, hey, yeah, some things are going to be different. Here's what's probably going to be different, here's what's going to be the same. Here's how you can help in terms of that support piece. 

New departments means how do these new areas relate to each other? What does this even look like? Do people feel like we can be one department or do people feel like all of these things just belong in very different places? New manager for me, frequently new skip level, usually new product and design partners. So sometimes the EPD, the engineering product design partnership would also change, which that relationship is super, super important. The engineering product design leads, making sure that they're working together really well, making sure that they're in sync, making sure they're communicating effectively.

So all of these new pieces, plus maybe handing off old work, creating stability and clarity, conveying a clear picture of the current status and what you want the future status of the department to be to new folks that I was reporting to. Again, you have two weeks to do all of these things and to get things feeling right and settled and back to work and sort of flowing.. So it's a lot of different parts and pieces, not to mention that you're also frequently onboarding to entirely new product areas. Deep product areas that you need to understand what's prioritized, what's deprioritized, what's problematic, what's not problematic, what are the dependencies with other teams? There's just a lot.

Yeah, change is hard for lots of people. 

So again, different people process this in different ways. I will say one of, as I became a little bit of a, I'll call myself a reorg veteran. As I became a little bit more experienced with reorgs, I like to turn them into more fun events to make them feel less stressful. So I set of fun Slack questions, get to know you questions that I would ask throughout, because there's always reorg day, right, where certain people sort of know what's coming but then there's the big announcement and the cascading comms. Tthen it's the day of also changing. At GitHub, we had to change all the permissions of the teams and rename team names, department names, et cetera. So it's just almost a lost day. There's a lot of logistics, there's a lot of new Slack channel creation. Small things.

So I had this set of questions that were things like, what is your most versatile piece of clothing? Or what is a piece of furniture that's been moved around wherever you live the most? So they're sort of all about changing and things moving around and versatility or being in different spaces, or what was the most frequent time that you moved in the period of time? Just all these. And so, yes, reorgs are stressful and different people feel different ways about them, but I had this list of questions that sort of made it almost humor.

It was like, okay, things are moving around, but oh, I have this shirt that I wear with a belt or that I wear on its own, or that I wear buttoned or unbuttoned, or it gave people a fun chance to talk about changes that hopefully don't feel so stressful. A piece of furniture that's moved around your house the most, and feel free to post a picture of it. That's sort of fun to recap for your colleagues and friends. So yeah, just creating a little bit of a lighter air around the day, I think, was really helpful. As I'm sort of digging in with the folks where reorgs feel more stressful, and talking to my managers new or old and being like, hey, who on your team should I touch base with first? Who really cares about what's going on? Who is this impacting? Who is this distracting for? How can I help? Who should I touch base with first sort of thing?

That's great. I think over time, you could develop a culture where change is common and people get used to it. But if there's any way in which we can begin to help that as a leader, that's great. I love that you brought personal questions and then also brought it to change.

Yeah. And that's also, now having worked at larger companies like GitHub and smaller startups, there's also a different feel. There’s a talking point that says, reorgs are good, it means we're growing. It means we're changing. It means we're evolving as a company.  And yes, I agree with that. And I think that in some situations, it's very valid to use that, especially earlier stage startups where people expect that more or understand that or where you can give a little bit more of a, sometimes I'll be like, hey, this is what I think the next year is going to look like so that people can anticipate those changes or just know that things are going to change without it feeling surprising or destabilizing.

I also think sometimes that talking point is used to justify changes that maybe should be justified in other ways. And I think that everywhere that I've ever been that's had changes in engineering reorgs like GitHub, not GitHub, all over the place. I hear it from tons of friends and peers at other companies. Frequently this is sort of a talking point that's used. Sometimes I feel like the talking point is valid and appropriate and sometimes it feels like performative or a little manufactured.

Right and even if it’s going to help us get better, we don’t want to ignore people feelings of loss, especially if they didn’t have any say in it.

How did you personally find stability as a leader in the midst of all this? How did you stay grounded and stable yourself?

I personally grew really quickly through reorgs so I definitely came to see reorgs as opportunities. I frequently worked with different people. There were new people to learn from, new styles, new scope. So for me, it was great. It was also really, really stressful. 

One of the things that I did is I put myself on a clock and I sort of would say like, okay, I will let this go on for X amount of time. Because honestly, I worked a lot of hours in those two, three weeks of leading up to and during height of reorg. Those were not 40 hour weeks for me. They were well above and beyond. I wanted to make sure that I was catching myself because it was not a sustainable pace and it was not a pace that I should be at forever. 

It's like, you should get over this initial hump of chaos and then there should be breathing room. So I would almost put myself on a clock to make sure that I was taking a day off or a couple of days off to sort of be like, okay, have I done the thing that I need to do? Are we over the initial hump? I need a day to sleep, breathe, relax, whatever.

That's so good. What is one piece advice you might have for others who are leading through a reorg?

Yeah. I have two pieces of advice. (laughs)

Two pieces. You can have two. (laughs)

First, reorgs can be very overwhelming. Determine what absolutely has to be done and what is nice to have done. So ruthless prioritization about the must haves, the nice to haves and the will come later.

Second, with reorgs it’s really easy to land on an us versus them path as a fast way to gain trust from your team. It’s easy to slip into this space, use it as a chance to reframe yourself. Figure out what talking points feel right for you that don't fall on that sort of us versus them path.