Episode 103: Emma Harrington on the Benefits and Costs of Working Next to Your Colleagues

This is The Visible Hand. My name is Jordi Blanes i Vidal. My guest today is Emma Harrington, an assistant professor of economics at the University of Virginia. Today, we are going to talk about her paper, The Power of Proximity to Coworkers, which she's joined with Natalia Emanuel and Amanda Palais, and is forthcoming at the Quarterly Journal of Economics. Emma, welcome to the podcast.

Thanks so much for having me.

So Emma, power of proximity to coworkers, that's obviously like topic that became very relevant in the context of the moving to working from home as a result of COVID and then the mandates to return to the office. While it is a very relevant, very important topic, there hasn't been, prior to the last few years, a huge amount of work about this question about whether there is any power in being proximate to your coworkers or not. However, There are a few papers prior to yours that study questions that are not exactly the same, of course, but that are somewhat related. Could you just summarize what is the state of the literature prior to your paper about how colocation, being proximate to your coworkers, what effects it has on the productivity, careers, well-being, just in general, in the context of the workspace?

A lot of this literature can trace itself back to Alan in MIT. in the 1970s who worked with IBM to study how proximity between different people at Bell Labs impacted the likelihood of communication and collaboration. And so what he finds is basic social decay, that if you're on just a different floor than some other scientists, then you're basically not going to collaborate with them almost at all. And even if you're just basically a basketball court away from another scientist, the likelihood that you collaborate is substantially lower. And since then, there's been multiple studies within academia that have shown similar things. So within MIT professors themselves, they're much less likely to collaborate if they're in different buildings. True even during building renovations. So if you're just randomly thrown together into the same building while your building is being renovated, you're substantially more likely to collaborate. So all of this is sort of suggesting that these small frictions to face-to-face communication really matter, that out of sight, out of mind does kind of occur quite literally, that people tend to be more likely to communicate with and then collaborate with people who are close to them. So that's sort of one related strand of literature. There's another strand of literature about remote work specifically. So Nick Bloom and his collaborators wrote a seminal paper about this. Going back to the 2010s, they worked with a company to run an experiment on remote work. And what they found there was that in the context of call center work, it looked like it was really good for people's productivity. to be remote, but they were less likely to get promoted. So it looked like it did have some of these career consequences, even in a context where it didn't have any negative impacts on people's productivity. So I would say that's like the general state of the literature as it was pre-pandemic.

So it is very interesting that you say that about the paper of Nick Bloom and his co-authors. I don't know whether he's the first author listed, but he's, I mean, by now, definitely most prominent advocate of the fact that working from home is widely used and not detrimental and so on, because the result on the lower likelihood of promotion that they find in their paper is not a result that they particularly emphasize. It's a result that is kind of hidden there at the very end. And the main message of the paper, and I think it is very useful how you mention this paper as in opposition to the other literature from the MIT studies from the '70s. The main message of the Bloom paper is, well, colocation is not that important. Colocation or remote work seems to have no positive effect on productivity, or at least a positive effect on the input, which is the amount of hours that the workers are willing to put. The amount of production per hour doesn't seem to be affected. affected, but at least the workers are more willing to put effort in, and therefore the company benefits from that. And this has been, my understanding, has been like the most prominent strand in the reaction, you know, to the shock of the pandemic prior to your paper, and maybe a couple more that have gone back to the early literature and say, well, actually, maybe proximity is really, really important.

I think you see that even within, so, Meta, example, they reacted really early in the pandemic with saying that we think that remote work is permanent here because a lot of their people were saying that they were more productive at home than they were in the office, and the data that they had at the time sort of bore that out. And then 3 years later, they kind of reversed course a little bit and pivoted towards a much more hybrid strategy. And part of their reasoning was that it looked like in the long run that it was pretty costly, particularly for new hires and young people, not to get the mentorship that they would have gotten in the office. And so it seems like the data that you can kind of get most easily is often on this quantity of work that seems like it's often positively impacted. And you're looking at a population that was just in person and had All the benefits of being in person sort of accumulated, and then it was working really well early on. And then in the long run, some of these costs can kind of materialize as you look more at the quality of work and you have more of the long run where some of that human capital may not be developed in the same way.

Is this also the— I mean, you're going to tell us later on in detail what your paper says, but is this also the main trade-off or message in your paper?

Yeah, exactly. So, I mean, we find that in general broad strokes, remote work is useful for writing more programs, especially for senior people who kind of know what they're doing. And it's costly for junior people in terms of their human capital acquisition and then also the quality of the code they produce.

So can you tell us what is the setting in which you're paper takes place. This is a real company, obviously. It's a big company. What else is important about it?

So, it's a Fortune 500 company that we've worked with for many years now and fortunate to have that relationship. And one thing that's really important about the company from our research perspective, they have this pretty big campus, their main headquarter campus that had at least prior to the pandemic, about 2,000 engineers roughly on that campus. And they have 2 buildings that are about a 10-minute walk apart. So there was some variation in engineers' proximity to one another, even pre-pandemic, because some teams could all be in one building and other teams ended up kind of by quirks of seating availability ended up scattered across those 2 buildings.

So one thing about this, so you describe it as a Fortune 500 company and that sounds enormous, but 2,000 people is not that many people. So am I right in concluding that coding is actually not the main production that takes place in this company? Not that this matters in any way, of course, right? It's still something that the firm wants to do as efficiently as possible. But 2,000 people coding, that wouldn't make a company into a Fortune 500 company necessarily.

Yeah, that's totally fair. So I mean, it is not your biggest 500 company. So that's also part of it. I've always had some concerns that it's going to fall out of the 500 and we'll have to edit all our papers. I mean, they're pretty comfortably in the Fortune 500, but I mean, software engineering is a big part of The firm—it's a it's a major retailer, so it has a ton of warehouse workers, a ton of customer service agents. So a lot of its population is not in software engineering, but you want to think of the software engineers as kind of doing typical types of tasks for a retailer. So they're maintaining the website, they're maintaining the backend catalog, they're now doing some stuff with AI to help with product recommendation. They're creating internal tools for other people at the company to. what you might have at a place like Amazon, but like scaled down substantially.

I know what writing code is because I do it every day, but I kind of do it by myself. Of course, maybe my coworkers look at it or whatever, but it's kind of an individual task. But here that it seems as if this work is kind of not individual, there is like a team component to it. Can you just tell us about how this production function works? Maybe if you tell us about it, maybe at the very end we can go back to the Bloom paper and see why maybe what they find is slightly different from what one would expect in this type of setting.

Yeah. So I probably know enough about software engineering, like just enough to be dangerous. I spent a previous life as a software engineer for a little bit. So, I mean, I think one big thing that is different about being a software engineer than being an academic economist who writes a good amount is that as a software engineer at one of these companies, you're going to be interacting with a really large existing code base. So you're not going to be writing something that is totally standalone. You're typically going to be When you add a program, it's going to be some sort of change to an existing set of code. That means there's more necessity for you to understand what other people have done in the past. It's also a setting where the stakes are higher. Like, we all care a lot about our code as academic economists, but we're not in a position that we can take down the website of a Fortune 500 company by making a mistake. These software engineers are in a position to do that, for better or worse. And so there's much more of a system for checking the work. So every time a software engineer is gonna write one of these programs, they're gonna have to have it reviewed by at least one other engineer. In our context, normally 2 other engineers who are gonna give them feedback, almost like a mini referee report on the code they write. Before it can actually enter production code.

So you were, you know, but I want to therefore explain that when you mentioned the word program, you were doing like inverted commas with your fingers, meaning that it's actually not a program the way that we understand it. Because there is only one program in a, in a way, or there are only like a few A very small number of programs. What you call here a program is just some chunk of code that is contributing to a program. Is that correct?

Yeah, that's a good way to think about it. So what we call, yeah, in air quotes, a program in our paper, it's often touching engineers going in and writing a quote unquote program. They're making a conceptual change that might stretch across multiple different files and even touch like different codebase. So when we're talking about this quote unquote program, it's really, you should think about it as a chunk of conceptual work.

Who assigns work and why are there teams in this type of context? So I understand you say that there is a team component, of course, in that my code is reviewed by somebody else. Okay. There's obviously a collaboration or team component to it as the way that we economists would understand it in that work is somewhat sequential and there are complementarities between the— or substitutabilities in the effort between different agents and all. But here you have actual formally defined teams. What does belonging to a team mean? And do teams have a boss? And does the boss assign tasks, in this case, programs to be written or chunks of code to be written? How is production organized?

So I think some aspects of it may be team-specific, although I think there would be general rules. So oftentimes a team at this company is gonna quote unquote own a particular part of the codebase. So they're gonna be responsible for that part of the code and other people may make changes to that, but it may need to actually pass through that team. And so you can kind of think about it as being pretty similar to how research might operate, is like you might have a team of people who are working on a common project. They have some synergies with other teams who are working on other projects, but they're kind of owning that chunk of work. So a lot of it is based on the, the set of tasks that they're doing. They may have their own What is called a product manager, who's kind of the glue between the software engineers and the business. They're going to help the engineers figure out sort of what does the business need them to do on that bit of code going forward. And the product manager is going to be kind of the one that's bringing in tasks to the team. And then tasks are constructed by the manager. They're going to kind of take the product manager's input and then sort of divvy it up into these technical tasks. And then those can be either assigned by the manager or often engineers themselves may take off the queue and add it to themselves when they've finished another task.

So there are teams then that are, you know, assigned to particular bits of the production process. I mean, for lack of a better way of describing it on my side. And this paper is about the power of proximity to coworkers, so therefore the other members of the team. What defines this proximity or not in this type of setting? You told us that there are 2 buildings that are 10 minutes apart. What decides whether the engineers in a team are in this building or in the other building or spread around and so on?

Yeah, so one building is bigger than the other, so more engineers end up in the bigger building. And then a lot of teams are able to find seats all together in one building, but good teams end up scattered across the 2 buildings. Um, much of these engineers are creating internal tools for other companies, so they're writing, for example, the software that the sales agents will use when they're trying to make sales. And so for those to be not only near one another, but also near the people who are going to actually be using the code and software that they produce, makes the sort of Tetris getting them into the same building particularly difficult. So those teams are more likely to cross the 2 buildings, but it happens for— teams of all different types. There's just like seating logistics that mean a bunch of teams do end up, it's in one building and some of the teammates in another. And observably, they don't look that different in terms of what teams end up all being in one building versus what teams end up scattered across them.

So I guess that this kind of answers the next question that I was going to ask you, which is conditional on being in the same building, are the engineers sitting next to each other? Because earlier you referred to the MIT or Bell Labs papers from the '70s in which you said that being on a different floor matters a lot. I actually have a paper on face-to-face communication in which being at a Euclidean distance of 4 is equivalent to being on the other side of the city. That is, the decay is incredible. So when you tell me, oh, this team is in the same building, I don't find this particularly impressive in terms of leveraging the power of proximity. I will find it impressive if you tell me that they are like shoulder to shoulder next to each other. If they happen to be, you know, scattered across different floors, I, you know, like I wouldn't expect that we can necessarily label this as high proximity.

That's totally fair. We, We tried to get from the company the actual seating arrangements of where people were located, and they just didn't have that in any sort of systematized format. And so they weren't able to share that with us. We would have loved to have that additional data and insight. I was embedded at the company for one summer to try to get additional data. And so I have some sort of anecdotal accounts of what it looks like. So on the engineer— one of the engineering floors at that time, if you would walk around, there were chunks of desks in their open office plans that would even— what that group of people typically did. So I think most of the time, if people were in the same building, they would be proximate to each other. But we don't have data on that to confirm that conjecture.

You don't really claim in the paper That, I mean, as you described just now, that the assignment of teams to like uni-building versus multi-building locations is random. Instead, what you leverage in order to study the benefits or costs of colocation is something else. What is that?

So we're utilizing the fact that If you thought that it was a causal effect of proximity that was causing these one versus multi-building teams to be different, then in their outcomes, then we would expect those differences to go away once the offices themselves all closed and everyone was remote. And so our biggest test is to basically see what happens when the office is closed. And in general, we see that differences between these types of teams and the feedback they received and their output tend to dissipate once the office is closed in a pretty sharp way, suggesting that those differences pre-pandemic were a reflection of proximity as opposed to something else that was different about those teams.

The research design is difference-in-differences. Exactly.

Difference-in-differences around the pandemic, you can always have concerns about. The pandemic was such a big shock that you might be worried that different teams that weren't reassigned to be co-located versus scattered had different types of tasks that changed differentially around the pandemic, or other things might be different. So we also do some other sorts of checks on the design. our sort of favorite is we have, so engineers receive feedback from their teammates. They also receive a lot of feedback from people outside their team. And so one of the things that we look at is, well, the feedback from teammates should be impacted by your proximity to those teammates. That should really matter. Whereas your feedback from people outside your team, That serves as a sort of placebo check for us. That shouldn't differentially change for people on these one versus multi-building teams. And that's exactly what we see, sort of collapse of feedback for— and then co-located with their teammates and then lose that proximity. That's really being driven by feedback they receive from their teammates and largely absent from feedback they're receiving from people outside their team. Which is harder to square with a story where all of this is just a spurious result of these engineers having different tasks or different needs for feedback.

Powerful test, but I want to draw attention to the type of language that you're using because you're somewhat, not in the paper necessarily, but right now as you are summarizing, obviously, you're Conflating 2 elements here. You are referring here to the fact that your teammates were co-located with you, and then during the pandemic, they stopped being co-located with you in the uni-building teams. In the multi-building teams, some teammates may still be co-located with you, right? So shouldn't, in some sense, the test be the type of maybe even more precise test? the change in the amount of feedback that you receive from teammates or even non-teammates that were in the same building as you and that then stopped being. You are using a powerful test, which is to study the assignment of teams to buildings, but in some sense, it is not your team that writes the feedback for you. It is a particular individual, and that individual even in the multi-building team may still be in your own building.

Yeah, that's a great point. We did do that additional test and it has results that are consistent with telling that the biggest impact are on co-located teams or these unit building teams and then on the feedback they receive also within building. That does prove The reason we're focused on this distinction between these scattered teams, these unit building teams, is we find some evidence that a different building does change the team dynamics. So one way to think about this is that some teams have this implicit policy that it's one Zoom. You have one of them to come into the same offices for a meeting, they're just all gonna move that meeting. Online and just like that. So I saw this a lot at the company that even with teams where most people were in the same place, they would all pull out their laptops for a meeting. And so they could accommodate people who were not. And so that can really shift the team dynamic, even among people who are themselves sitting next to each other. They're just not having these daily opportunities. to interact in the same way as if their whole team was co-located.

I think that this is a plausible explanation, and it is made even more plausible by the fact that, as you describe in the paper, they have daily meetings that are this agile type. Even if there is not that much to discuss, they are supposed to meet every day and therefore develop that type of team camaraderie that maybe operates at different levels in person than online. But let me emphasize that even if we are meeting on Zoom, even if we are having the formal team meeting on Zoom, if we are still in that corner of the building that you describe under the tag of Team B, it will seem to me that some of the benefits of proximity are still likely to be acquired, correct?

Yeah, I think that's totally fair. And I mean, we don't emphasize this a ton in the paper, but you do see that feedback across the board declines when the office is closed. So even among those teams that were distributed from each other, you do still see that feedback does take a tumble. And we don't make as much of that because we think Well, some of that could just be the pandemic was really the loss of proximity. With the multi-building teams, they still have doses of proximity, and then they lose that when they go fully remote. So I think that that's definitely consistent with it. I went into a bit of a deep dive into the neuroscience literature on proximity, and it does suggest it is pretty delicate, our face-to-face interaction. So there's one study that I That I love where they have people interact with one another. And in some treatments, they just have a glass sort of screen between the people. So they are just looking at one another. In others, they replace that glass with a computer screen that's just showing a live feed of the other person. And even though those 2 people are actually in some ways literally face to face with one another and they're in the same room, Using a computer screen feed rather than just that live interaction still reduces how much their kind of brains get in sync at a neurological level. So I think there is some reason to think that our interactions with one another are kind of delicate in some ways, and these sorts of frictions can kind of meaningfully matter.

I'm definitely sympathetic when we have anybody in my group. The only question that I ask, in addition to, okay, is this person a good researcher or whatever, is, is this person going to show up? And are they going to have an office that is next to mine or definitely on my floor? I'm going to see them every day. Otherwise, I don't want them as colleagues. You know, it doesn't matter how good they are. Just to interrogate a little bit, you have told us at the beginning that this is what these engineers are supposed to do.

Yeah.

So, they write what you call programs, which are like chunks of code that go into the main program of the company, and that they are assigned these tasks by the product manager, and that they're also supposed to review each other's code. But how much? Presumably they are not paid for performance, right? They are not paid per word or per keystroke of code that they write. So I would presume that their incentives are very flat, at least not linked to these type of like quantity-based measures of performance, what determines the percentage of their time that they're supposed to be doing one thing or another? And I'm asking this in the context of, if we want to understand why proximity would encourage people to give each other more electronic feedback relative to being further apart. I understand that these things are fragile, but what is it in the motivation of these individuals that is being altered? And what is their motivation supposed to be? How is it in an ideal world that they're supposed to allocate their time? And are they doing too much when they are next to each other? Or are they doing too little when they are further apart?

Yeah. So you're right that there's no explicit performance pay. We've talked to engineers and they kind of like will cock their head when we even sort of suggest they have a lot of not great comp, for example. It is, there are soft incentives. So we talk to people at the company and they'll say that in performance reviews, they will Think about code quantity and sort of the velocity with which people are writing code and think about the extent to which people are, are being mentors. And the weight on mentorship increases as you become a more senior. So they want people in higher-level roles to be shifting away somewhat from writing programs themselves and towards a more code review mentorship focused workflow where they're essentially kind of scaling up their production by having other people write the code and then they spend a lot of their time reviewing it. I think it's a hard to answer question. There's too much or too little feedback. The way we handle on that is we went back to the company. The reason I was embedded there was to get more data on code quality, to basically understand, is all this feedback at least making the code better? And so, in general, we find evidence that suggests yes. So, especially in people new to the proximity, is helping them write code that is less likely to introduce bugs and also less likely to basically quickly be deleted, likely because it was impossible to understand by other people, or just going in kind of a bad direction. And so that's not definitive proof that proximity is moving you in a good direction, because there are these trade-offs. These senior people are getting less done themselves when they're working with their junior colleagues more. But for these companies that care a ton about the reliability, it says, My sense is that they'd prefer to have slightly lower velocity of code and higher quality, which it seems like proximity is helping them achieve.

So just to be clear, this is the exact same regression that you described earlier. That is the interaction between the post-pandemic period and the previous to the pandemic being in the same building dummy. But now with different left-hand side variables, correct?

We would have loved that if that were possible. So unfortunately, they only have code quality data back to December of 2020 to look at what happens around the pandemic for code quality in the way that we can for feedback and coding quantity. What we instead do with code quality is 2 different things. We look at, well, were people in, who were trained on these one-building teams who got more feedback, did they write higher quality code in the long run than people who were on these scattered teams who received less feedback? And so that, generally speaking, suggests that these people on, who got this more greater intensity of investment, and their human capital. Once we look out to December 2020, a ways later, they're writing this higher quality code. Even when we look at 2 people on the same team at that point, one who had this exposure to one building teams, one had this exposure to scattered teams, the one who had been on a co-located team in the past tends to write higher quality code. So that's Not the perfect design, but is sort of suggestive that this is human capital acquisition. The other thing that we do is we look at what happens when the offices reopen. So we can look at our difference-in-difference design basically in reverse. See, do differences across these co-located versus scattered teams reemerge? When the offices reopen. And that design, which we view as the stronger one for this, suggests that when the offices reopen, code quality improves for these co-located engineers more than it does for these scattered engineers, with gains concentrated among people who are new to the firm or relatively junior in their career. As an aside, we also see that returning to the office is again costly for the senior people's time. So they again write fewer programs when they're reunited with their junior colleagues.

So I just want to emphasize that the 2 regressions that you just mentioned, or the 2 results that you just mentioned, are qualitatively different. They are speaking to actually very different things. The second that you refer to is variation of your earlier, your, if you want to call it like that, your baseline finding, but now having quality on the left-hand side, as opposed to quantity, right? Because you have that it is the contemporaneous production of the engineers, especially the junior engineers, but the engineers that move from being all remote into a uni-building team, as opposed to a multi-building team, that goes up. That is, it has less bugs or less code that is deleted or back and forth or some other measure of quality that you have. In some sense, that's obviously very illuminating and reassuring, but not that different from your early result. The first thing that you mentioned just now goes a little bit beyond that, in that it speaks to human capital accumulation. That's not quite the same thing, right? Because it could be that you correct my code and therefore the code gets better, but it doesn't mean that I learn anything out of it. Now, this result that I just referred to is kind of the other important leg of your paper. Because it speaks to the thing that you were mentioning at the beginning, that the downside of being remotely located, especially as it refers to extrapolating to other companies, is precisely this lack of training or lack of accumulation of human capital that people have been concerned about.

Yeah, we think that that is totally the right interpretation. We also, to try to add more of a case that it is this human capital acquisition that matters in the long run beyond just action about this particular piece of code. We also look at some career outcomes. So for example, whether people are more likely to be able to land a job at a better firm if they were on one of these teams and got more investment.

Before you move to that, and because I don't want to lose track of this bit. Could you describe a little bit whether the economic magnitude of these effects sounds reasonable to you? And I'm not saying that it does not, because I find it difficult to track the number of comments per program and how many programs there are and how much. But if somebody corrects my work, maybe I'm a slow learner, but it doesn't mean necessarily that I'm going to improve immediately, right? And here, some of these regressions that you have, like for instance, in your baseline regression, you have that there are 1.47 more or less comments per program in one type of building relative to the other. That doesn't sound like a huge number. Obviously, I guess you have to multiply it over time and by how many programs we are reading and all this, but the differences, could you make the case that the differences are big enough that we would expect that sometime later the human capital accumulation paths of engineers who have been lucky enough to end up in a uni-building team deviate so much upwards that you can pick it up, statistically speaking, in your regressions?

Yeah. I mean, I think one way to contextualize the 7 number Is that people don't get a ton of feedback on any one given program. So they're receiving roughly like 9, 8 or 9 comments. And so in percentage terms, that magnitude is more meaningful. So it's roughly like a— I guess my number, my math isn't quite computing, but it's roughly 20%. A fact. So they over lots of programs, I think, full. So our main analysis around the closures is using engineers' contributions to the main code base. The return to office, we have that data. We have a sort of broader scope of what engineers are doing, writing more programs per month. So If you believe that what we see around the closures is sort of representative of what is happening for those, I would need to kind of scale it over all of what they're doing on the main codebase. Likely lower bound on the differences in feedback that engineers on these 2 diffs— oh, we can see some suggestive evidence of that even in the code reviews themselves, that mentions of discussions on Slack, for example, about the code are— more likely to happen on one-building teams than these multi-building team engineers. And so the discussions in the code reviews themselves are reasonably expansive and very substantive, but they're not necessarily the entirety of the conversation about the code. And so to the extent that there's more conversations on Slack about the code in these one-building teams and more conversations face-to-face in those one-building teams, we're getting sort of a lower bound on the differences across these different types of teams.

But the number of programs, the number of programs per month is not that big either. Is that right?

Yeah, I mean, maybe I overstated it. I mean, I think the code reviews are a meaningful chunk of the human capital transmission. The firm wants them to be a good record of the conversation between the engineers to kind of understand why additional changes were made to the code beyond what the engineer initially did. But yeah, it's only one channel. So I do think that regression that you suggested would have excluded engineers on one-building teams. Like, I mean, we think part of the mechanism is that they have more in-person conversations with their teammates, and that leads to more online feedback, but it presumably also leads to a bit more in-person feedback as well.

I'm going to paraphrase what you have just said and see whether you agree with me. So, we have the feedback, and imagine that we also have a measure of human capital. I know you don't quite have it, but let's imagine that we had it. We wanted to estimate the effect of feedback on human capital and we were using the unit building versus multi-building as an instrument, the exclusion restriction you are saying wouldn't hold, right? Because being co-located is affecting human capital accumulation through a variety of channels, both online and offline, out of which you are only measuring a small part.

So I was going to go in the direction of thinking about sort of their long-term or medium-term, I suppose, career trajectories. So similar to the design of looking at code quality in the long run, we can also look at differences in departure rates for better firms for people who had been on these one-building teams and got more investment versus these people on these scattered teams. And so what we see is that admins with their teams are more likely to exit for better jobs elsewhere. So you can think of it as moving from this kind of smaller Fortune 500 company to like the Googles or Amazons of the world. It's like a common transition. And so those are more likely to happen in general, and that's really being driven by people who are young. As well as it's more pronounced for women. We didn't talk about this so much, but in our earlier part of the conversation, but the effects on feedback are also much more pronounced for women than men. We— there's some suggestive evidence part of this is because it looks like when women are not proximate to their teammates, they're a little bit more reluctant to ask a lot of people for feedback and less likely to ask follow-up questions. And so for the 2 groups where you might think general human capital is most sensitive to proximity, we're seeing these effects on their likelihood of being able to take sort of the next career step to move to some higher-paying, more prestigious firm.

Sorry, I interrupted you. You were going to tell us that there are other ways in which we can evaluate that this is like a meaningful improvement in the careers of these young engineers as a result of something that you were going to say?

Yeah, I mean, I think I went into it with more confidence about the ability of technical interviews to deduce people's human capital. So I'm not sure we would have found this in many other settings, and I don't think technical interviews Of software engineers are perfect, but I do think it's an unusually human capital-oriented hiring process where they're really trying to like you know about programming best practices and the sorts of things that you might hope would be transmitted by my sort of bullishness about it. I think the other component of it is like COVID was a time where there was reasonable in this population. There was suddenly opportunities to were not geographically co-located with this. Firm. And so that did lead to a little bit more of a shakeup in who was at the company. So I think that probably helped us with some statistical power. And I mean, I don't want to overstate things. The differences here are not enormous. So it's not like the multi-building teams never— those people never leave to better-paying jobs and the one-building teams are enormously more likely to do So the differences are significant, I think, economically and statistically, but not like night and day from one another. Yeah.

So let me emphasize now that this is a remarkable result, but I want to mention this. It is remarkable in that you were able to find anything at all here because— so you have data that goes back only to 2019. So this is just one year prior, you know, to everybody being online anyway. We know that there are changes of workers across teams and everything. So, you know, it is possible that if you measure them in 2019 as being co-located, maybe in 2018 some of them were not, right? So the intensity of the treatment is not necessarily perfectly measured right there and now. Okay. Then you have that the difference comes in like a small amount of feedback that they receive online. So in addition to maybe additional channels online and offline and all that. But as a result of that, they are able to gain human capital. There is sufficient turnover in a firm of 2,000 coders such that we can measure who goes where, right? Because typically in many firms, there is not a lot of turnover, right? Only like 5%, 10% leave every year. And these engineers that successfully managed to accumulate more human capital and left as a result of being co-located also managed to convince their future employers that they had higher human capital, which is not obvious, right? you write a bunch of stuff in there and you are better, it's not obvious that necessarily Google is going to hire you. If it had been my paper, I probably wouldn't even have run the regression in the expectation that it was a waste of time. And yet, you know, you ran it and somehow you found that there were statistically significant meaningful effects.

Yeah. I mean, it was surprising to us that it was so immediate. I mean, I think one thing that we can see directly in the comments themselves is that there's often this sort of back and forth exchange during the code review. So it's not just that you get a set of comments, but often there's like follow-up questions that, that ask to try to understand that feedback better. And a lot of the effect is coming from those, that follow-up exchange. So when engineers are not proximate to their teammates, they're less likely to ask follow-up questions. So then there's less, as a result, less follow-up on the part of the commenter. So there's just some of the conversation just doesn't happen as much. And that seems kind of human to me. Someone, you might just hesitate a bit more. Follow-up question that might make you sound Like quote unquote stupid or something, or ill-informed, and you just are less willing to put yourself out there when you don't have some of those trappings of of a human to human relationship that you would really get in person. So I think that's probably some component of it. We also see that people are less likely to reach out to as many people as meant to their teammates, so they kind of. Like in your example, you might tutor over and over again, as opposed to going to a variety of people once you're remote. And your mentor just might have less to say about a certain part of the code than someone who you don't quite as well, but knows that part of the codebase really well. And so the movement towards that sort of safe person may also be part of the mechanism here that like just going to one person over and over again may reduce the total amount of feedback you get.

Tell me now about the hiring in the firm.

Yeah, so what we see at the firm is consistent with them being sort of at least subconsciously aware of this sort of mechanism that we talk about in the paper. So when the firm went remote, For the pandemic, they shifted towards hiring much older engineers, so almost a decade older. And then once they brought people back to the office with a reasonably aggressive, at least for tech, return to office mandate, they again shifted towards hiring new grads again, younger engineers. And so their hiring patterns within the firm is consistent with those decision makers feeling like, well, when we can't be sure that we can build people's human capital internally. We just want to buy that talent elsewhere by hiring people who have lots of experience.

But where are these people coming from? Because presumably every other firm that is in a similar production process was also bidding for these experienced engineers. So how come that they ended up in this firm as opposed to— I understand that their wages went up. But why did they end up in this firm as opposed to somewhere else? Like, you could think alternatively that Google was doing something similar and it encountered the same type of process and it was bidding for the same type of workers and it got all the experienced workers. And then this firm hired even more juniors just by paying them a lower salary that was proportionate to the lower productivity that they thought that they were going to get.

Yeah, no, that's a great point. I mean, I think anecdotally talking to some of my friends at tech, what they've noted is that it seems like you just had a big movement of software engineers from small firms during the pandemic to large firms. So I think there, there may have been some movement from our sort of medium-large firm to even larger firms. But I think it looks like empirically, at least judging from this firm, there was sort of a movement. At least the dominant force was like a movement into the firm as opposed to out of it. But I think that's a great point. And I mean, I think To me, in some ways, the return to office results on hiring were more interesting than the closure results because so much was happening with the closures. It was like a weird time for many reasons. The firm was having like some, some shifts in, in demand for its products and so forth. So I think there was a lot going on there. The return to office is like, uh, more— there's more variation across firms and when that occurs. And this firm was like more aggressive than a lot of other tech companies. So I think it makes more sense that then they would have this sort of strategic advantage of hiring these relatively inexpensive junior people, um, once they've gone back to the office more than some of their peers did. Um, yeah.

Um, if I am a junior person, do I ask for a higher salary if I am hired by your firm and they tell me that I'm going to end up in a different building?

I'm not sure that most of them would know that they were going to be in a different building at the point that they were So they are not aware necessarily of the type of mechanisms that you identify here, even though they may learn about them over time. Yeah, I think that's probably true. I mean, one thing we do see is that when the offices do reopen, young engineers are more likely to spend more time in the office. So that's at least consistent with them Knowing about some of these mechanisms. I mean, they may also want to socialize more, and there may be other things happening there, but it is consistent at least with this sort of demand for proximity to accelerate their human capital development.

What do we take from this paper into wider lessons? And I think it's a lot, but I want you to mention, uh, mention it. What is it that we can extrapolate here to a wider society lesson about whether working from home is a good idea or a bad idea, whether the government should encourage it or not, whether firms will have this type of policy or not?

Yeah. I mean, I think our paper highlights this big sort of intergenerational trade-off from remote work that people have talked a lot about, sort of different winners and losers from remote work. And there aren't sort of big trade-offs across other groups of people, but we're sort of highlighting the fact that for young people it looks pretty costly, and for more senior workers it looks like may be much more productive for them. They may have some career incentives even to want to be remote so that they can boost their own productivity, which may be more rewarded at the firm. And so from sort of a societal perspective, it suggests that we may be worried about this generation of people coming into the labor market. How they're going to fare in a world that is more remote. And sort of consistent with that, at the end of the paper, we talk more suggestively about the fact that unemployment actually for young people in remotable jobs has been relatively elevated ever since the pandemic, whereas for older people, it has actually been relatively low relative to the pre-pandemic period. And we don't see that sort of age pattern for non-remotable types of jobs. And so it suggests that for young people, it may be remote work, maybe make it harder to build their human capital and even to find a job in the first place.

The good news, I guess, is that since the arrival of all the LLMs, there's not going to be any work for young people anyway. So they don't have to worry so much about this problem.

Yeah, no, I mean, I think there's, Sometimes I think of it as sort of like the 2 henchmen of the apocalypse for young workers, that it's like remote work was really tough and then like 2 years later they are hit by AI. No, I think it's a really hard time to be a young person. I mean, I think there was an interesting discussion with someone at Anthropic who was saying that actually with AI now, the skills that you need to be successful are kind of these more conceptual ideas about like, well, what, what do I even want my programs to do at a high level, as opposed to like exactly how I write them? And you might think that sort of tacit knowledge is going to be even harder to transmit remotely.

Thank you, Emma, for coming to the podcast.

Thanks so much for having me.

Please visit our website, thevisiblehand.uk, for links to other papers that we have mentioned, Introductory Music and Logo by Etana Nesiso, Episode produced by Rizzy Ambalaga.