The Post-pandemic Office: What actually works best for software development?

Organizations of all sizes and industries are placing software at the core of their business to stay competitive, and that means fostering high-performing software development teams who are able to ship code continuously as the product is honed to better serve the end user.

At a time when organizations are experimenting or fully committing to an all-remote, all-in-office, or hybrid work culture, business leaders should be guided by the consequence on team performance in the long run. The past two years have proven that some teams and businesses can be surprisingly effective when working remotely. Therefore, it has become increasingly pressing to come up with a well-defined strategy for the role of the office post-pandemic. Mandating 100% in-office does not feel like the future that employees expect: the toothpaste is out of the tube because of employee relocation and employer competition for scarce and diverse talent. Some leaders mandate one of the extremes, and some propose what they see as a compromise in the form of two to three days per week in the office. The tone of the conversation can feel more like an argument between management and employees, souring what should be a time of celebration of the chance to work together again. I find that too often leaders are led by employee sentiment, or an industry trend, or vague generalized corporate guidance, rather than solving for what is effective for the work in question – in this case, for what actually works best for software development.

To frame the discussion: I’m going to talk about building the type of software that used to be built by teams who used to work to some extent physically together in an office. There are other traditional models for building software, the most well-known and vastly different example being open-source software development in which people may never meet each other, who speak different languages, who don’t work for a common organization, etc. Let’s oversimplify to stay on track. The former is best suited when fast iterations are needed on “product market fit” (that is, for iteratively building software based on testing a sequence of hypotheses); in this mode a cross-functional team needs to optimize for highly effective communication. The latter is best suited for a more well-known problem statement, and longer-term development of functionality that is less buffeted by changing requirements. Here I am talking about the former situation, and we’ll assume the business goals of that context.

For such an effort I believe that in-person is in fact always the best way to develop software, but of course that is no longer a realistic demand, and in truth it was always difficult at any kind of scale. I also acknowledge that building remotely seems to work better than I expected at times, and we should build on what we’ve found effective over the past two years. So, how should we be guided when we think about setting up teams to work at peak performance? What is the role of the office at all in the future?

Transform the culture of collaboration

The key insight to start with is that well known trope that high individual technical ability alone, while of course an advantage and to some extent necessary, does not alone translate to a high-performing team. The most talented engineering teams don’t always succeed, no matter their expertise, skill, or technical choices of platform, framework, etc. Instead, I would go as far as to argue that by far the most important quality of a high-performing software team is excellent collaboration and communication. While this too is a common position, and perhaps even generally agreed upon, I believe our industry is still in a state of confusion on what is most important to get right, and too often falls back on individual qualifications and technical choices as the main areas of focus. Perhaps it is for this reason that we are struggling with what we are solving for in the “back to the office” debate.

To start to decompose “collaboration,” let’s consider the culture of teamwork among two subgroups:

1. Business input: Today, software is never done, product definition happens continuously as part of an ongoing feedback loop with the end user. A set of hypotheses are created that propose functionality to solve for what are believed to be the needs of the end user, along with a set of metrics for validation. Based on results, the product direction will need to change week to week. That means that Product, Design and Engineering team members need open lines of communication in order to move as one unit at speed: requirements need to be discussed cross-functionally to get at the key hypothesis, the best and most effective associated functionality requirement, and the best and fastest way to implement it. This amounts to a need for massive communication throughput between team members and a culture of candor and quick resolution to team friction when it inevitably arises.

2. Engineering: The fact that software is never done means that engineers are constantly writing, changing, adapting, and optimizing their code. The goal must be to stay productive come what may (indeed, I often define a high-performing engineering team to be one with a low variation in its week-to-week output.) It follows that engineering practices must prove themselves as contributing to that ongoing high productivity. An example is that a team must be resilient to employee transitions to avoid slowing down when a team member is absent who is responsible for some silo of the codebase; that means a shared knowledge of the “whole” codebase by the whole team, which leads to techniques such as pair/mob-programming.

As stated, our industry is not entirely aligned on this framing, and certainly not in the urgency in adopting this whole mindset. However, what I would call more progressive teams have generally adopted some form of the associated techniques for the past couple of decades. Over that time, these modern practices have been honed, but usually assumed in-person was possible.

When the pandemic hit, the availability of collaboration tools such as Zoom and Slack allowed many organizations to transition to remote work immediately. Those who were already proficient using more effective remote tools for video, code collaboration, whiteboard, messaging, etc. fared much better than those making the best of clunky, legacy tools. These tools can work surprisingly well to keep teams connected, and many of the practices designed to solve for (1) and (2) were quickly adapted to work remotely (e.g., remote pair programming, remote standups, remote iteration planning meetings, etc.). It was a pleasure to watch teams steeped in the “why” of the theory rethink the “how.” But a few months into the pandemic I noticed that things were starting to fray. I saw signs of increased friction between product and engineering team members; I heard from engineers that work had become less satisfying; I found that teams new to these ways of working struggled mightily to make the shift, despite traditional proven tactics that usually help transform a culture.

I have come to believe that, in simple terms, it is possible to continue a culture when remote, but it is impossible to create a culture when remote. We, as humans doing something creative and challenging, in which communication is paramount, need to be together physically in order to successfully define new working norms or to form a shared understanding of the goals of a new project. There may not be different information formally communicated when in person, but when we are together, we are much better at picking up what could be termed “everything between the lines,” or the multitude of micro-habits that make up the “how” of working together. Of course, that is one definition of culture: it’s in the little things we do. I am reminded of the scene in the film “A Few Good Men”: a rule book is presented as containing all that is needed to know about how to behave in the Marines, but when asked where in the book it is written where the mess-hall is, the soldier admits that “I guess I just followed the crowd at chow-time”.

Aligning in-person collaboration with the product life cycle

Concretely, then, when I think about what an office should be for, I think of solving this problem as the primary goal. When we have a new team; when we have a new project, or one shifts in focus; when a project runs for a long time; this is when we must bring people physically together. Once a culture is formed, or refreshed, then we can “get away” with remote work. An important corollary is that when we decide to be “remote” it must be explicit and universal: if there happens to be a subset of the team that is together, they must avoid the temptation of interacting differently, for otherwise subcultures form that no longer solve for the whole. (This is just the “one-remote, all-remote” pattern that sprung up well before the pandemic.) It follows that organizations don’t need employees to be in the office all the time, but in order to have high-performing teams there are times during a product’s life cycle when in-person collaboration is a must. But those must be intentional, well-planned sessions, designed to promote the formation of teams and working norms.

First, the most obvious time to bring employees together in person is when a new project kicks off or a new team is formed. Getting the team together for the first week or two, especially if it’s a new team forming, can help establish cultural trust. I have found that for new efforts, software practitioners resist this less than might be expected: it is exciting to be part of a new effort.

• An in-person kick-off meeting with stakeholders helps the team identify the goals of the project and align with stakeholders on their expectations. It helps the team “get it” far better than when remote. This means that the myriad of micro-decisions the team members make over the long term are far more aligned with the stakeholders goals. The team moves more quickly and stays on track once team members return to their remote working locations.
• Offline sessions such as meals, tech talks, or hearing from stakeholders informally create a type of experience that allows for rapport, candor, and second order discussions to take place. While useful in themselves, more important is that they allow for much improved future collaboration and trust later, when not physically together.
• Arguably most important, consecutive days spent doing “normal” day-to-day work massively accelerates the calibration of working norms. A few days a week with only partial participation of the whole team at any given time don’t accomplish anything like the success of one or two weeks of solid back-to-back interaction.

Second, for longer-running projects it’s important to get together physically to refresh the culture. I have been surprised more than once over the past six months when seemingly intractable disagreements that caused serious friction even on high-functioning teams seemed to disappear after one in-person offsite. In some cases it wasn’t even that a difficult issue was finally solved by deep in-person collaboration – it was that the issue magically disappeared altogether. It was just a mental block on how teammates understood each other when remote. Therefore, my recommendation is to bring teams together every, say, three months for a week of in-person collaboration. This can be when more resistance comes up – it is not obvious to us as humans that making the effort to get together is important for the health of the team and success of the business. We need a bit of encouragement. Therefore, I recommend making these ongoing get-togethers be more like “events”:

• Timing them to celebrate product releases further establishes camaraderie among the team and can drive momentum into the next release through launch.
• Hold a team meal that feels special; invite a senior executive to speak; time them with watch parties for company town halls, etc.

Thirdly, what I believe does not make sense is the “compromise” of management asking employees to come in 2-3 days a week. I’d question that in two ways. First, practically, it brings up an “us and them” dynamic of those who live near enough to an office to come in versus not, and it’s harder to optimize a real estate footprint around. But secondly, and more profoundly, the mandate is too divorced from the work. It doesn’t respect the product life cycle; it doesn’t make certain of using the time for specific high-value activities that form a culture; and it is all too easy for the employee to consider it simply a less oppressive form of drudgery than five days a week. Perhaps that last part sounds cynical, but without a “why” attached to the work itself, software practitioners quickly become frustrated with what come to be seen as arbitrary rules.

Software development is a creative endeavor that is much more productive and much less risky when teams have moments of “togetherness.” The business need is best satisfied when teams respond quickly to end-user needs, which calls for a level of collaboration, communication, and trust that isn’t possible to create and maintain when purely remote. We need to think of the office as a tool that is critical to enable a high-performance team culture, and experiment with its use in that regard, and then we’ll get it right. Whether or not remote work takes a more permanent place in how an organization operates, the guiding principle must be to foster a culture of collaboration that aligns engineering teams with the business goals.

To learn more, visit us here.

IT Leadership, Remote Work