Search
Search
Han Yuan
February 1, 2024

SE Radio 601: Han Yuan on Reorganizations

Han Yuan, an accomplished Chief Product and Technology Officer, joins host Priyanka Raghavan to discuss reorganizations. The conversation starts with a broad discussion of reorganizations and reasons that companies choose to undertake them. They then consider organizational behavior and topics such as Conway’s law and the theory of constraints. Han offers some advice on key steps to take when planning for a reorg, including how software teams could organize themselves based on technology, frameworks, or user journeys. The episode ends with some discussion of metrics and lessons learned.

Show Notes

Related SE Radio Episodes

References

Transcript

Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.

Priyanka Raghavan 00:00:19 Hi everyone, I’m Priyanka Raghavan for Software Engineering Radio. Today I’m chatting with Han Yuan who has more than two decades of experience in guiding high growth, high scale organizations for better growth. Having been employed at various companies as small as 25 people to Fortune 500 companies, unicorn-class startups, and organizations in between, Han has personally initiated over half a dozen reorganizations impacting hundreds of individuals and has been a participant of various restructuring efforts and hence the right guest to help us understand the topic of reorganizations. We will try breaking down the reason and intentions behind reorgs and hopefully having someone like Han tell us what happens behind the scenes will make us more enlightened. I hope so. Welcome to the show, Han.

Han Yuan 00:01:06 I’m excited to be here. It’s going to be a fun topic.

Priyanka Raghavan 00:01:09 Okay, so let’s jump right in. In the first question I wanted to ask you is how do you define reorg and what is the reason why a company or companies go for a reorg?

Han Yuan 00:01:21 I define a reorg as any kind of shuffling of roles and responsibilities that impact at least more than two groups. I think if you shuffle a group around within a team, it sort of doesn’t count like, Hey Bianca, I’m going to promote you to a technical lead. But if you have two teams and their roles are changing, I consider that to be a reorg. And of course, depending on the scale of the reorg, things can be more complex accordingly. In terms of the reasons I thought about this deeply, I think there are potentially a lot of reasons, but there are sort of the five mainstream reasons that I can come up with. The first one is operational efficiency. As you become a bigger and bigger company, eventually you’ll find that the way you’re structured might be slowing you down. And so it’s sort of like in technology and software we have similar issues, right?

Han Yuan 00:02:10 Imagine you wrote a piece of software, you’re hosting it, but it’s just not efficient because of the way it works. It could be a monolith; you need to deploy the whole code at once. It’s impacting your CICD pipeline. It’s fundamentally inefficient and you could potentially increase hosting spend or potentially hire a lot more people to do the same thing. Or potentially you could rewrite it so that the operating costs and the hosting costs are lower. And similarly, sometimes companies run into the same issue where the way we do work is inefficient and so they’ll rethink like, hey, how do we reorganize the assets that we have to be able to do the same work with less money? Related to that is just straight up financial health. For most software companies, human resources cost is the number one cost.

Han Yuan 00:02:59 And so in order to dramatically impact financial health in a positive way, in cases where spend is too high, that’s where layoffs occur. When you have a layoff, you’re effectively sort of doing the same thing, right? You’re saying–hey, we need to continue doing the same things but with fewer people. And so now all of a sudden you have fewer people, you have a bunch of empty seats, what are the roles that need to be filled? You could have a strategic shift, you’re entering new markets, you could be divesting new markets. In those cases you might need people with new skills that were different than the folks that you had. One of the more famous stories that, many folks I’m sure on your program are aware of is when Netflix moved to the cloud, they had a bunch of data center folks and they decided to let them go because the data center folks had a skillset that was very, very different than the cloud engineering operations that Netflix is well known for today.

Han Yuan 00:03:53 That was a major strategic shift that ultimately helped them move into streaming in a very, very aggressive way. You could have M&A, two companies join and as a result there could be duplication of roles. So again, reshuffling and sometimes you just have external changes. Covid for example, when Covid hit a lot of companies panicked, they laid off a bunch of people, then all of a sudden this is awesome and they hired a bunch of people, right? That’s an external change. I do think things like technological shifts, like generative AI could have a huge impact. A very specific example, you got to wonder like how companies like Stack Overflow are going to survive in this new world. They’ve had a huge hit in traffic. Other examples include Quora, right? Where if you go to Quora these days, they actually show some generative AI answers.

Han Yuan 00:04:40 It’s interesting because for those brands to survive, they need to have a major strategic shift and maybe the personnel that they had before, it’s not going to fit the new world. Now there are a couple of other things that I think folks sometimes dream up. A new leader gets hired like a fancy VP and they’re like, I want to put my stamp on the organization and I’m just going to reorg a bunch of people so that looks good on my performance review. I’m not going to say that doesn’t happen, but that’s not usually a mainstream case. Other cases you could have somebody who wants to bring in past coworkers and things like that and so they need to clear room. That does happen as well. I would consider them somewhat fringe cases that generally do not impact folks beyond senior leadership.

Priyanka Raghavan 00:05:22 That’s really fantastic. So what really piqued my interest from what you just now said was also, is there another case where I’m thinking about like, I guess it’s similar to the strategic intent that you said. So foresight sometimes I don’t understand this. I’ve had a case in the past, examples where been part of an organization where there’s this fantastic research team which is doing really cutting edge research and then suddenly one day that unit is just shut down. The reasoning is of course they don’t really give you very many reasons to everyone. But do you have some take on that, like does foresight play also a very big role in this or is that also like, would you say pretty low in the ranking of why you would do a reorg?

Han Yuan 00:06:02 Oh, what do you mean by foresight?

Priyanka Raghavan 00:06:04 Like you feel there is this cutting edge research, like that’s what I’m saying, that someone’s working on maybe like this generative AI but then at some point everybody’s thinking, oh this is the school team that’s doing this really awesome work and then the team is just shut down. So I just want to know about that kind of cases. Why does that kind of thing happen? Because they seem like these shining stars that, nothing can touch and then they’re also affected by it.

Han Yuan 00:06:25 It’s funny you should ask, because that happened to me before. I used to be the head of engineering for the eBay equivalent of Google X. So it was like a big incubator inside eBay Inc. Before eBay and PayPal split. So I know this problem really well. I’ll tell you why it happens. I think for businesses ultimately whether or not a group is effective comes down to three things. Is your team helping the company make money? Is your team helping the company save money or is your team helping the company save time? And I think the innovation teams that you’re describing, they typically have a very finite window to be able to generate significant results. The problem is that when economic headwinds come, that window starts to shrink dramatically. The only way those groups are typically protected is they need to be protected at the board or at the CEO level where they’re willing to run them as loss leaders.

Han Yuan 00:07:18 So when I first joined eBay the first time, I had a very similar role within the first two to three months we took over eBay mobile and it went from a hundred million dollars in GMB to 3.3 billion in GMB in 22 months. For the company, they’re like okay, that’s pretty good, right? There’s innovation works. The second time I was there after a stint where I joined Netflix, we spent two and a half years there and we did not have a hit. We tried a bunch of different things. I think the company was very impressed with sort of the things that we were trying to do and sort of the PR that we were generating at the time. The reality is that we were not helping the company make money, we were not helping them save time. We were not helping them save money. And when push comes to shove and Carl Icahn comes in and blows the company up we just could not survive.

Priyanka Raghavan 00:08:07 Okay, so that makes sense. So actually it almost looks like the biggest reason for reorg must be mostly financial. And I guess the question I wanted to ask you on this, how do leaders then decide which group is impacted? What are these behind the scenes discussions like?

Han Yuan 00:08:23 Thereís usually a thesis. So if it’s not directly financial like we need to shave X millions of dollars. So let’s take that case more around operational efficiency. Typically what happens is an executive need to describe a problem statement. These are the reasons why we need a reorg. For example, we might want to split the group up into two divisions and allow them to operate independently as full stack organizations so that they could operate autonomously. And today it’s all mixed up. Maybe you have a head of engineering and a head of product, and they have two silos, right? And so now you need to mix it, but the intention is to allow two product lines to run simultaneously. That is a problem statement. You designed a solution to solve that, right? Like what would success look like in that environment? What are the missing pieces? And then you start shuffling people around on paper without people knowing.

Han Yuan 00:09:17 That’s how that conversation typically starts. The financial conversation is I think typically started with just a number and then when that happens, it goes down to the next level, which is what is the department level spend? And there may be benchmarks around what the industry is spending, especially if you’re publicly traded, R&D for example. There are, if you’re publicly traded, R&D spend is something that folks really look at very carefully around comparables. So if you’re say a technology marketplace, you might be expected to have R&D as a function of spend to be somewhere around 15%. If you’re say an infrastructure company like Snowflake, you might be given a lot more leeway in terms of spend and so you could have now 30 or 40%, but some of these may be guided by external investor pressures that you have to hit that number.

Han Yuan 00:10:07 From there, there’s a sort of Russian doll aspect to it to look at, well now which groups are more expensive, which groups are not? And that’s where the targeting comes in. I mentioned this because if you’re a leader and you have a budget, one of the best ways you can do to shield your team is to always think about how efficient you are. It’s very tempting as a leader to think I want to grow my career and I want to manage hundreds of people or, dozens of people, it might make me look good or make me feel good. But the opposite happens when things get rough and you’re in these conversations, you’re the one that’s asked to pick and choose who stays and who goes. And that’s not a very fun place to be. They

Priyanka Raghavan 00:10:46 Might have trouble sleeping at night. I guess let’s also talk a little bit about the operational efficiency angle and in that, I guess I should ask you about two laws. One is of course the Conwayís law and then the other one on theory of constraints. Now how does that relate to reorganization? Is that used a lot when you actually plan a reorg?

Han Yuan 00:11:04 It is. A very specific example, I was at a company once where the teams were all mixed up and they were really kind of separated to some degree by entities in the system. So you can think like users or checkout or something like that, right? But then there are like sort of business initiatives and some of the business initiatives are making what the features and functions that work right now work better. And then there are a bunch of initiatives that are designed to attract new customers. Now you can imagine a world where like the folks that are handling existing customers, they have a different operating cadence. They have a different go-to market strategy, maybe their UIs are radically different, maybe they even want to use different frameworks, but the teams were all mixed together. And so this case, how the outside world sees your products maybe as two different things, like these are existing customers and these are new customers are very different than the way your teams are structured.

Han Yuan 00:11:56 And so eventually you have to mirror the two and that’s the idea behind Conway’s law, which is your organization ultimately mirrors how people consume your products. That definitely drives things and over a period of time you will see shifts. When you’re in a mixed-up state, oftentimes you’re limited in efficiency, you’re constrained, right? There’s like kind of a limiting step. It could be like, oh I need to hand off this piece of work to this team now or this team needs to surface an API to me and so therefore I’m stuck, right? Those are the kinds of conversations that sort of you have across the aisle that may slow things down that otherwise need have to be if you were all say working on the same team. And so those constraints once you identify are important because the idea behind theory of constraints is if you think about say developing software as a pipeline of activities, as software engineers, we get really excited about making things better, right?

Han Yuan 00:12:49 But the truth of the matter is there’s probably one thing that we’re all doing in our work that’s, or in our process or something that is the limiting step. Like that is the one thing that is really clogging up the system. And so we can make things better ahead of the pipeline or we can make things better behind the pipeline, but it won’t make the whole system smoother. And so a part of reorganizations is both being very mindful of whether or not our organization reflects the products we build while simultaneously unlocking those constraints in the system that may oftentimes be a function of how teams do the work specifically in handoffs.

Priyanka Raghavan 00:13:28 So, taking a cue from this I guess the other question I wanted to ask you is it sometimes feels that some organizations are fairly stable whereas other organizations, seem to change very frequently. Is there any science behind that?

Han Yuan 00:13:42 In my personal experience, it has a lot to do with leadership. One of the fascinating things about companies is many companies will have core values, but how the company operates is somewhat a reflection of the leadership. It starts at the very top. You’d be very surprised at how much impact the CEO has on the culture of the company, like their personal quirks will resonate across the company. What I will also say though is that just like an organization has a hierarchy, right, like a tree, the nodes underneath the CEO also create a hierarchy and so they create their own subculture so it’s like a Russian doll. And so stable organizations sometimes can be, even if the company as a whole is chaotic, if the executive owning the group operates in a fairly stable way or if they have strong protections in terms of how they do the work, they can create stability.

Han Yuan 00:14:33 One of the things I think folks don’t fully understand with respect to how executives work is a big part of executive work is to be able to communicate the value of their organization to everybody else. Not just the CEO but also the stakeholders and all of the middle managers. When you’ve done a good job explaining the relevance of your organization, how you’re utilized, how effectively you’re managing spend, how you’re helping the company make money, save money or save time, you have a much better chance of creating stability for your organization. And so for experienced leaders, this is a top-of-mind issue all the time because there’s two kinds of reorgs, right? There’s you, let’s say you’re head of engineering and you’re like, I want engineering to work better so now I’m just going to mess with things. There’s a totally different scenario which is outside forces saying hey, you need to change, you are forcing that change via financial or whatever reason. You must have the mechanisms to justify that.

Priyanka Raghavan 00:15:30 Okay. So then in that case I think it’ll be a perfect segue to understand a little bit about the organizational behavior. So there are some questions I wanted to ask you in this regard. So why is it that it appears like there are some people who are in the know about this reorganization and some are not? So what’s the kind of pros and cons of say the company or the organization letting people know that a restructuring is going to happen? Could you maybe explain that with an example?

Han Yuan 00:15:54 I’ve done it. My personal preference is to give people visibility that a restructuring is going to happen at the very high level. Give them some guardrails around when it’s going to happen. I think people can take bad news if it’s expected. I also think that in cases where there’s going to be a serious systemic shock, I think the right thing to do is to give people the agency to potentially be able to look for other work. Because a lot of times individuals know that they’re underperforming and to give the opportunity for the underperformers to self-select out, I would argue is financially beneficial for the company because you don’t need to pay severance as well. And so I think in that case it’s a win-win. The downside is that if you do not have your ducks in a row and you do not execute this fast, so let’s say like hey we’re going to do a reorg and it’ll be finished February of next year, what a disaster, right?

Han Yuan 00:16:49 Everybody’s going to be paralyzed, they’re going to be worried, nobody’s going to be working, it’s no good, right? So you want to be organized before you let people know and you need to have a process of mind around how you’re going to execute it. Once you have transparency, you can bring people over the curtain and discuss this. In terms of people who are typically in the know, I would say they have two qualities. One is they have visibility in the chain of executive leadership and that’s important because if I don’t know who you are, I don’t know how to bring you under the curtain or if somebody else doesn’t know who you are, they don’t know how to seek your advice. The other piece that is critical is somebody who has insight into the quality of the work of other people. So there are certain individuals that are more accessible in this regard.

Han Yuan 00:17:39 You’ll find that program managers oftentimes are brought into the loop, even junior program managers. And the reason is because they interact with a lot of people, and they have visibility into the contributions of those individuals. Managers of course are brought into the loop. You’ll strangely find that sometimes middle managers, especially managers of managers like directors and things like that, they’re not brought into the loop. The reason is because A, they could be impacted by say a riff and then B, many times they don’t know how the work is actually done for better or worse are effective and they’re basically a pass through. It’s fairly nuanced. A bonus would be the individual has to have discretion. There’s certain individuals in the company that are known to be gossipers and that will make things very, very difficult when you execute a reorg.

Priyanka Raghavan 00:18:25 Oh. So what are the sort of best practices that you’ve seen in your various roles? Conducting a reorg, what’s the best way to create a discussion about the reorganization with your leadership team coming from A CEO?

Han Yuan 00:18:39 The most successful reorgs really nailed the why. They are very good at explaining why are we doing this down to each individual move that may be controversial. I think unsuccessful reorgs appear random, they appear arbitrary, they appear unfair. But if you play back those reasons and maybe you have reasons too, right? Reorgs you’ve experienced think if you do the five why exercise, you’ll realize that actually you don’t understand why. Why was that innovation team let go, which was one of your earlier questions, right? We don’t know. And then people have those questions, but if you were told like, hey, they were costing a lot of money, it didn’t look like anything was going to be produced while and it’s either their salaries or maybe yours, then maybe you’d be okay with it. Being able to communicate the why in a respectful but transparent way I think is the key. Too often leaders want to just move on to reshuffle everybody, but they’re like, okay, take a break and let’s go tomorrow. It doesn’t really work that way. You really have to work with the organization to heal after a significant change.

Priyanka Raghavan 00:19:42 That’s really insightful. So be transparent about the reorg, the whyís as you said. And then the second thing you said is also give time to actually soak in the reorg. So I think you, those are the two main things right?

Han Yuan 00:19:53 There’s some work to be done around identifying those key individuals that you want to stay and work with them.

Priyanka Raghavan 00:20:00 The other thing I wanted to ask also in in terms of the culture of the company and how it impacts the reorg, which you kind of talked briefly about in the beginning, would you have examples like specific examples that you don’t have to name companies but, where the culture, really helped the reorganization and it went well. Or maybe it also be nice if it’s maybe linked to some countries, like if you’re from Bhutan where they have this happiness index or something, is it reorg better in a country like that than say like I don’t know any other country. I’m not naming anything else but yeah, that’s what I wanted to ask there.

Han Yuan 00:20:32 I think the best example is Netflix. For context for your listeners, I was at Netflix circa 2010, 2011. I was in charge of the mobile efforts at the time, which was very nascent at the company. So I helped lead the teams that built many of the mobile products today and we also played a role in evolving Chromecast and things like that with Google Direct. So I was there for a while. The period of time that I was there was some of the most hectic times ever. Carl Icahn tried to break up Netflix too. The company tried to split itself from DVD and streaming. There was also a big price change at the time, the first that it ever been done. And so there was massive subscriber discontent and cancellations. We also launched in 32 countries in Latin America and then UK and Ireland and then finally this is all old news, but during that time we also went into original content.

Han Yuan 00:21:23 That was all happened in the 15 months that I was there, , okay, so there’s a lot of change, right? A lot of systemic pressures. I remember there was an organization that made a mistake at one of our country launches and a hundred people lost their jobs after one of the country launches out of nowhere. What’s interesting about Netflix is it was totally normal. Like nobody panicked, people just expected it. And the reason is because Netflix has this very complex culture deck which they, they share with everybody and they really talk about how they don’t view employees as part of a family, they view them as part of a team and they’re very clinical in terms of how they make personnel decision. And so when you join the company, you know this. For many times during my time there and the company was at times we didn’t have enough office space and so I did not have a cube so I sat in the hallway with a portable desk but occasionally the janitor would move my desk.

Han Yuan 00:22:19 I tell you this story because every time the janitor moved my desk, people assumed I got fired. And so when they would see me walking around the halls, they’re like, I can’t believe you’re still here. I’m like, I’m still here, I’m doing a great job. They wouldn’t fire me, but it’s just part of the culture and so if you happen to be in that culture where change is normalized, people are okay with it and they did an amazing job of allowing those people who are okay with, pretty dramatic change to be able to just slough that off. Counter example is Google. So I’ve never worked at Google but, Google did some pretty big changes this year. I know a lot of people who worked at Google and when you joined Google for like the last 10, 15, 20 years, it’s effectively getting tenure at a university.

Han Yuan 00:23:02 People expect it to be lifelong employment. And so the idea of layoffs or the idea of your friends getting laid off is such an anathema that folks at Google are really struggling today and it’s because the way the culture was centered historically versus the reality of what they had to do is jarring. And of course leadership has changed right across time. This is no longer Larry and Sergei’s company, but that cultural shift has to be managed in a way that is not so jarring. You could also make the argument you need to pull the band aid at some point. It’s going to have a huge impact in terms of how your organization evolves. And so a lot of this homework in terms of what happens after reorg is probably already laid bare in the foundations of the culture and values of your company.

Priyanka Raghavan 00:23:50 That’s I think two very good examples. I think you’ve driven home to the point very. So thank you for that. And I think now we can segue a little bit into say software and reorg, like how you would say build software and reorgs, do they play a part? So a lot of questions are coming from that. The first thing I wanted to ask is in terms of certain companies you have like a product function and an engineering function which is separate, but sometimes they get combined into one function like chief product and technology officer. So what are the pros and cons of having this approach?

Han Yuan 00:24:22 The biggest pro is that you have one person who owns both sides. This concept is important because if you think about it from a product person or an engineering person’s head, they create moral hazards for each other. So let me explain. Let’s say you’re the head of product and I’m the head of engineering and I tell you, hey, we should stop building all features because we need to break up our monolith into a microservices platform and it will take five years. As the head of product you’re going to be pretty upset about that, right? Because this is impacting your ability to evolve the business, so on and so forth, right? If the organization lets me have its way, then what are you going to do for the next five years? The flip side happens. So from an engineering perspective, I think that we deal with this all the time where the product person says, you say it’s going to take like two months and the product person says ship it in three weeks, cut a bunch of corners and just do it.

Han Yuan 00:25:12 Well guess what? Who gets the sev calls in the middle of the night when things are not going right? Customers are complaining, not the product manager, the engineers do. And so these types of trade-offs are oftentimes best managed if there’s one person managing them and if you have to reconcile that at the CEO level who also has to run sales, marketing, operations, so on and so forth, they’re just going to be two split headed. Those are great examples when you might want to put it in one person. The downside is that the person you hire becomes very critical. They might be more of an engineer or more of a product person and so they will have biases and then the second thing is that they may be weak in the domain. I, for example, have held product and technology roles simultaneously, but generally speaking I do not take on those roles if I don’t have expertise on the product side.

Han Yuan 00:26:03 So as an example, I’ve been approached for work in healthcare, I don’t know anything about healthcare and I’m too scared as the head of product to make a bad decision about a healthcare product decisions. So I think in those cases you really need a domain expert. So those are some examples where there may be reasons why you can’t even do it and there are reasons why you might want to combine them. The final thing is that combined roles, hiring that head typically is very difficult. So if you speak to executive recruiting firms, it represents somewhere between, two to 5% of their searches. It has been increasing in the last two to five years and so I think from an industry perspective what you’ll find is there’s going to be more demand for those individuals. So those searches are increasing but they’re still a fairly low percentage, like probably under 10% even in 2023.

Priyanka Raghavan 00:26:53 The next one I wanted to ask is to dive a little bit more into this, say the structuring I’ve been in like teams where you are actually split by say confidence entities or libraries or even domains that you work on. Is that a good way of restructuring?

Han Yuan 00:27:09 The entity model I think works for fairly stable situations. Oftentimes you do need that entity model anyway because if everybody does everything then nobody owns anything. So that’s very useful. The challenge with the entity model comes when there’s a lot of entropy happening in the system and because what you’ll also find is some initiatives might be cross-cutting across many entities. So for example, the user entity. The user entity might be a classic example of a limiting factor, right? Everybody wants to get onto the user entity’s roadmap and so if the user entity is affiliated with one initiative or another say like the marketing team owns the user entity, then they’re going to block out effectively every other person’s request to that entity. So, how you organize initiatives is really important. If entities are completely disassociated with initiatives or user journeys, you’ll oftentimes have problems because you’ll find that those user journeys are going to be either be broken or you’re going to work around them.

Han Yuan 00:28:11 So, for your listeners, like a user journey might be the acquisition flow. What happens when the person goes from the visitor site signs up and then does their first transaction, if the visitor site and the signup is disconnected from the first transaction, then every time you want to acquire customers, right? Every time you need to make a change to the teams that’s doing the first transaction, you have to get on the roadmap and things get slowed down. And so potentially you might want to reorg all the entities around a user journey where there might be like a GM around it, but it can be done.

Priyanka Raghavan 00:28:44 I think that makes a lot of sense because I think it would also be useful for the user because if you follow a user journey. There’s another question I wanted to ask also. In terms of some organizations they also consider like say dedicated frameworks, components, and platforms when while they’re restructuring, what’s your take on that?

Han Yuan 00:29:02 I would consider them constraints in the problem of reorganization. I’ve been in companies that have this where you might have like old PEARL code or old PHP code. Unfortunately those individuals are so kind of landlocked because it’s very difficult to take a PEARL programmer and put them on the front end and do JavaScript, right? I think in the long run there’s motivation for administrators to standardize their stack as much as possible because that way you can move people around. The second challenge that I think is a tension within most technology companies in terms of frameworks, how much of you build yourself versus how much of an ecosystem do you adopt that has a vast number of libraries. It might be intuitive for engineers to just say, well I’m going to use like the most heavily adopted ecosystem, why would I use Ember versus React, right? Which has a ton of packages. One of the things that you’ll start to realize and that there’s an amazing blog post by Spolsky in like the early 2000 where he talks about the Law of Leaky Abstractions. Let’s tell your readers about it.

Priyanka Raghavan 00:30:03 I’ll definitely add, I don’t think I can summarize it, but I clearly remember that and I remember being so struck by that post, it was beautifully written. I don’t think I have it in the show notes there, but yeah that’s something to add.

Han Yuan 00:30:14 The Law of Leaky Abstractions is amazing because what it says is effectively the things that we use, libraries, frameworks, and things like that to save time, eventually they become their own maintenance headache because they may have bugs that are outside of our organization. I personally had this issue where I have open-source projects and I rely on libraries; they don’t get maintained anymore and next thing I know I’m forking the source code and I’m coding code that I don’t even fully understand just to be able to make my code work. These are the kinds of things that are technological decisions that may dramatically impact how you deliver your product. In our world, I think some of the larger tectonic changes I remember include like, Magento 1 and Magento 2, those are totally incompatible. Angular, Angular 1 and Angular 2 totally incompatible. How many people got bitten by that transition where they had a full-on Angular app and then they had to rewrite their entire front end just for Angular 2. That’s painful. How you choose your frameworks can dramatically impact not only who you hire but also what work you need to do.

Priyanka Raghavan 00:31:21 It’s very interesting, very insightful since you talked about frameworks, I also have to ask you, does it also make sense to have a dedicated architecture team or an enterprise architecture team in this scenario then?

Han Yuan 00:31:32 I personally, me versus best practice, I prefer to have the senior leaders to be very technical, the people managers, at least at the architecture level. Because I think it’s very hard for people managers who manage engineers who are not technical because that means that they don’t understand how the game is played. I view them as coaches, this is like having, imagine a sports team where the coach has never played the game right or doesn’t understand the nuances of games. I think that’s not a good precedent. Now with that being said, I think the more senior engineers, that can be expensive and so in order to get economies of scale sometimes it’s useful to have a group of very senior engineers in an architecture group that can provide guidance. However, how you run that group can be done in many ways and some of them are very bad. The architecture group for example, is oftentimes the limiting factor because teams are forced to essentially go through an architecture review, the calendar is backed up and suddenly software is not shipped. That’s not good, right? As a leader and as somebody looking at the structure of the organization, you must make sure that the architecture group itself does not become a limiting factor.

Priyanka Raghavan 00:32:41 You’ve got me thinking there. Yeah, that’s really good. Yeah, good one over there. I guess I was going to ask you a question on whether engineering managers should be able to write code and I think you’ve kind of said that they should be technical. So would your answer there be say yes?

Han Yuan 00:32:52 I think so. Also, I wonder why they wouldn’t be able to write code . I mean maybe I’m just old school, but I think writing software is so fun. I think real technologists, first, I will say most engineering managers, if they’re really good at engineering management they do not have time to write code at work. I don’t know why engineers wouldn’t write code even if they don’t have the ability to do it full-time and, in most engineering, managers shouldn’t have that time because they would otherwise be doing a disservice to their org. But writing code is so fun. I think if you stop writing code, you stop being able to empathize with your team at a deep level and I think that becomes problematic when your team says–hey, my work life is not as fun because of this or that. You won’t understand why they’re complaining. One of the biggest reasons why engineers complain about burnout isn’t because they’re overworked. It’s because they’re doing work that they don’t want to do. Most software engineers have had this experience where they’re in this flow, right? They’re re-coding and it’s working and they’re coding. Nobody gets burned out when they’re having fun. You have to have the ability to empathize with your team at that level at a very deep level.

Priyanka Raghavan 00:33:59 I’ll ask you now the other roles which we usually see, which is to do with what’s the difference between say project manager, a scrum master, a program manager, or sometimes you also call, you have a product operations specialist.

Han Yuan 00:34:13 I think prior to the early like 2000, most projects were actually run by engineering managers. So effectively the scrum master or what we call scrum masters these days is the engineering manager. They would figure out who does what and then say this is when things are due. I think that has shifted dramatically. I think there, one of the big reasons is because the industry doesn’t have real tools to bring up engineering managers and so engineering managers oftentimes are particularly good at driving deliverables and so the engineering manager role has been marginalized and this has now propped up multiple different roles. Generally speaking, I think a lot of the things that you talk about like the different titles, they’re somewhat synonymous, which is either getting the team to do something or coordinating efforts between different teams. They can’t be important. I think you’ll find that the most efficient organizations still run it away where the engineering managers are the ones that are responsible for delivery. I found that organizations that have a lot of non-engineering folks responsible for delivery, they can’t be rather bloated.

Priyanka Raghavan 00:35:19 Okay, so I’ll step back one level I hire because I want to ask you a question also about what are the different ways in which a company can structure, say the security teams, like between corporate IT and the platforms and sometimes I also see that in many organizations, the IT or the CISO, they report to the office of the CFO. So could you explain?

Han Yuan 00:35:39 IT versus AppSec. Let’s start with that one. The problem with AppSec reporting into traditional security is that AppSec engineers are much closer to software engineering. And so to get the best result, a lot of folks decide to embed application security within infrastructure teams. I think that’s a very common modality, but it can be a fight because, an HR perspective, it’s weird. You’re like why is there a security person here when all the security people should be here? And so that’s where you see that tension. But I think you’ll find that most heads of engineering would prefer to have AppSec in-house and then hopefully also make sure that AppSec is not one person’s job. So hopefully AppSec is advocacy and that AppSec is everybody’s job and so that we build security into the code upfront versus trying to QA it out on the backend.

Han Yuan 00:36:29 That’s just not going to work. With regards to why IT sometimes moves into the office of the CFO as the company matures, especially in the US where compliance becomes very important, IT becomes more of a compliance exercise and an audit exercise. And so you’ll find that the typical IT checklist, like how do you offboard the employees, how do you onboard the employees like, so on and so forth. That sort of like checklist activity feels more like accounting and so they end up effectively in the accounting realm. As a person who has managed it before, I will also tell you that IT struggles getting managed by a head of engineering. The head of engineering is typically interested in building things, running a business. They’re not really interested in figuring out whether or not what the new MacBook replacement policy is for the company or whether or not we should, renew our G Suite license.

Han Yuan 00:37:23 It’s such a big task switch even though it’s all related to computers. There’s a third thing though that is in the middle, and this is where things get complicated, which is oftentimes you have internal applications and whether or not internal applications should be part of engineering or the office of the CFO, this is where things get very messy. What happens to the data warehouse? The finance folks oftentimes need the data warehouse to reconcile their books. You do not know how much the company has made without deep integration into the data pipeline into production. Salesforce integration is a constant problem for many people. Does Salesforce and Salesforce integration live in engineering or in the office of the CFO? My personal sort of lived experience is that for better or worse, some of these domains can get rather complicated and so they’re better off being held back into the office of the CTO along with all the data pipeline work and keeping the data warehouse up.

Priyanka Raghavan 00:38:18 Since you talked about data; I mean this is a little bit different. I wanted to ask you about the relationship between analytics and data science. Again, that you see that there are some companies choose to combine both of these teams, the analytics and data science and some keep it separate. So why is that? Why does that happen?

Han Yuan 00:38:35 I think the root of the issue happens in terms of how the analytics team is used. There are many forms of analytics, right? There’s product analytics and then there’s like say I would call them like more corporate analytics. In corporate analytics you might have things like forecasting as part of their workload. They’re different workloads, but product analytics becomes really problematic because the reality is data scientists actually do a ton of product analytics themselves. If you look at their typical data science pipeline, the first part is sorting the data, right? And then they have to clean the data and then they have to augment the data and then they have to look at the data , right? A large part of their work is deeply understanding the data. And that can be augmented by folks that are actually in the analytics space, that frees up your data scientists who actually think about building the models themselves. I would consider to be related but quite different.

Han Yuan 00:39:30 So they’re very complimentary. The challenge is that if you just strictly look at analytics, there’s a bunch of iron that the analytics teams use regardless of your product analytics or corporate analytics. Like you might need a star schema, or you might all own a data warehouse. And so now things get tricky again between say engineering and some other function because who owns keeping that database up or that data lake up. So it really, really depends. Most of the time I would say these decisions are largely dependent on who the heads of the organizations are and whether or not they know the domain or not.

Priyanka Raghavan 00:40:06 The last question I want to ask in this section is, is there an optimal team size for software engineering teams that is good for productivity and efficiency?

Han Yuan 00:40:15 I think everybody has an opinion about this. So I’m going to state the opinions of famous people. Andy Grove, he’s the former Intel CEO founder. I don’t know if he’s a founder, but he is definitely Intel for many years. His number is seven. He says that the optimal number of people to manage for any manager is eight, which means seven direct reports plus the manager. Over the years, I have found this to be largely true. There are some individuals that can do an amazing job of managing more than seven. There’s a maybe a question as to why it might be true. My personal theory, having like, read research papers on human performance and short-term memory, it turns out short-term memory for humans is seven chunks. This is also why in some countries like the US phone numbers are seven, it’s like an area code plus seven digits.

Han Yuan 00:41:04 Back in the old days people used to memorize phone numbers. . These days it’s irrelevant, but you could have a huge number but, for old people they remember that they used to have to memorize the phone numbers. So that’s why the phone numbers are seven and I think you’ll find that managers are going to be more effective at seven. I think when you have lower, let’s say you have a manager of four people and let’s say they, all they do is management. The obvious and uncomfortable question is what do those people do all day? And especially if they manage managers, then there’s a real question as to what value does that manager add? And so when you look at reorgs, oftentimes the middle managers are impacted because the flow of information, those middle managers end up being a pass-through. What managers, they have a very uncomfortable job. I’d like to say that managersí main jobs are two things. One is to say no or two is to say yes but or yes and. The whole reason that person exists is to reframe the work. If you just pass the work through, then you’re not needed. Then the person at the top will just tell your people to do the work. You don’t need to be there. Those managers that don’t manage a whole lot of people end up being at risk of getting cut.

Priyanka Raghavan 00:42:12 Okay, that’s a good tip to know I think for the listeners. Yeah, we’re coming towards the final part of the show, and I have to ask you a few questions. Like now that we’ve gone through a lot of the reasons why reorgs would happen and about software, I wanted to ask you, how do you measure the success of a reorg? Do you have any examples that you can share of an organization that had considerable market success after reorg?

Han Yuan 00:42:35 I think we had quite a bit of success at Upwork after our reorg. So we did a big reorg once right before we went public. Very similar to what we described you and I just talked about where we identified certain key user journeys, and we affiliated those domain teams with those user journeys. So effectively the user journeys had a GM. So for example, the acquisition teams, they would be very focused on the user onboarding journey, and they had metrics that they were trying to drive towards. But they also had all the domains that would allow them to generally make the changes they want without talking to say another GM. And I think that was very, very effective in the sense that it allowed teams essentially a scrum of scrums to be able to operate fairly independently without getting on each other’s roadmaps. And they effectively had a collection of teams.

Han Yuan 00:43:26 And so with each month, rather than going through, large roadmap reviews, you would just talk to each individual team and say–hey, what were the things that you tried to do this quarter or this month? We did monthly OP observed reviews and, how did your metrics change from month to month? That was very, very effective. Some of the initiatives, one of them ended up propelling the company to an IPO in 18 months. The other metric that I would say is just employee happiness, I think you’ll actually know if it works fairly quickly because employees will tell you when they don’t work, and the employees will tell you that it’s working. And so if you can pull off a change and people are very excited or they’re like, this makes so much sense or they’re very motivated that you’ve done a good job. But it’s very hard to pull that off when you’ve let people go. I think anytime you impact people, it is very difficult to call success just because of the nature of what happened.

Priyanka Raghavan 00:44:21 How do you recognize failure? Is that just through employee feedback or again the operational efficiencies?

Han Yuan 00:44:26 Yeah, this, I think different people will answer this differently. So I can only answer it in my way. What personally bothers me is when I see leaders operate reorgs, they let people go and then they hire the same people back very soon that happens to me, that shows that the job was not done well. I don’t know if the employees will ever recognize that. Of course everybody’s happy that oh they came back to the company. Wonderful. To me it shows a lack of foresight and thought that there was not clear thinking at the management level that you had to do that. I’ve also seen companies that cut too deep and then they try to improve morale through team events and things like that. That to me, like from an employee perspective might seem okay, things are better, but from my metric of leadership it means that you did not do the job. I think if you’re going to do something hard, you try your darnedest A not to do it and then B, not to undo it. If you undo it, it’s not successful. You did not do a good job.

Priyanka Raghavan 00:45:26 Okay. So I guess the last question I want to ask you is based on all this that you’ve said, is there any personal experience or maybe an example where you learned a valuable lesson from a mistake that you made during reorg?

Han Yuan 00:45:37 The biggest mistakes I’ve made have always been due to communication. I have a preference, as I mentioned to signal reorg early, so I do not like to surprise teams, but the problem is that that puts an enormous amount of pressure to execute that reorg. And there have been times when, I was not able to get the management team to align fast enough on the reorg and so it just kept dragging. That is very, very devastating because it impacts the roadmap, it impacts morale, and also people start leaving. Sometimes the people you want to keep start leaving, which is bad. I think being very careful about moving as fast as possible is key, but there are so many unknowns you just don’t know like who’s going to disagree with you, who has a different opinion, whose input you need to get, whose buy off you need to get. Those things are very, very difficult to predict.

Priyanka Raghavan 00:46:25 I wonder if there’s kind of testing that you can do before the actual reorg like, scenario, like a DR scenario test that we usually do. I want if that’s something that happens into a reorg.

Han Yuan 00:46:34 In this case where I made a mistake before I signaled it, I had drafted a 25-page memo on the whys various solutions and broad strokes. I thought I had alignment. When you start putting names to boxes, I couldn’t get it together. It’s really hard because I forgot who said this, but I think engineers do this too. We plan a lot, right? We do a lot of planning and the reason is that we want to anticipate problems ahead of time. The challenge is that the biggest problems that we face are usually the unexpected. So no amount of documentation I had was going to help in this case because the things that I got burned by was outside of the 25-page document. So I don’t know what to do.

Priyanka Raghavan 00:47:13 That’s all the questions I have and it’s been quite insightful. Thank you for coming on the show Han. I guess before I let you go, I guess the question I need to ask is where can people reach you in cyberspace if they wanted to?

Han Yuan 00:47:25 You can reach me on LinkedIn. You can find me as Han Yuan. That’s spelled H-A-N-Y-U-A-N and you should be able to find me. I have funny hair. So that’ll hopefully identify me from everybody else.

Priyanka Raghavan 00:47:38 Thank you. Once again, this is Priyanka Raghavan for Software Engineering Radio. Thanks for listening.

[End of Audio]

Tagged as:
Join the discussion

More from this show

Menu

Recent posts