To stay competitive, organizations of all sizes and industries are placing software at the core of their business, and that means fostering high-performing software development teams who are able to ship code continuously as the product is honing to better serve the end user.
At a time when organizations are experimenting with all-remote, all-in-office, and hybrid work cultures, business leaders should be aware of the consequences on team performance in the long run. The past two years have shown that some teams and businesses can be effective when working from home. It is pressing to come up with a strategy for the office post-pandemic. The toothpaste is out of the tube because of employee relocation and employer competition for scarce and diverse talent, and mandating 100% in-office does not feel like the future that employees expect. Some leaders want one of the extremes, while others want a compromise of two to three days per week in the office. The tone of the conversation can feel like an argument between management and employees, souring what should be a time of celebration of the chance to work together again Too often, leaders are led by employee sentiment, an industry trend, or vague corporate guidance, rather than figuring out what works best for the work in question, in this case, for software development.
The type of software that used to be built by teams who used to work together in an office is something I am going to talk about. The most well-known and vastly different model for building software is open-source software development, in which people may never meet each other, who speak different languages, and who don’t work for a common organization. In this mode a cross-functional team needs to maximize for highly effective communication when fast iteration is needed on the product market fit. It’s best to use the latter for a more well-known problem statement and for a longer-term development that is less buffeted by changing requirements. The business goals of that situation will be assumed here.
For such an effort, I believe that in-person is 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 scale. 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. When we think about setting up teams to work at peak performance, how should we be told? In the future, what is the role of the office?
Transform the culture of collaboration
It is well known that high individual technical ability alone is not enough to make a high-performing team. Excellent collaboration and communication is the most important quality of a high-performing software team, no matter their expertise, skill, or technical choices of platform, framework, etc. While this 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. We are struggling with what to do in the back to the office debate because of this.
Let’s consider the culture of teamwork among two different groups.
- 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.
- 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.
Our industry is not completely aligned with this framing, and certainly not in the need for it. The more progressive teams have generally adopted some form of the associated techniques for the past couple of decades. Modern practices were usually assumed to be in-person.
Many organizations transitioned to remote work immediately after the Pandemic hit because of the availability of collaboration tools. Those who already know how to use remote tools for video, code collaboration, whiteboard, messaging, etc. were better off than those who didn’t. Many of the practices that were designed to solve for (1) and (2) were quickly adapted to work remotely, and these tools can work surprisingly well to keep teams connected. Teams steeped in the theory rethink the “how.” I noticed that things were starting to fall apart a few months into the epidemic. I heard from engineers that work had become less satisfying and I found that teams new to these ways of working struggled to make the shift despite traditional proven tactics that usually help transform a culture.
It is possible to continue a culture while remote, but it is not possible to create a culture when remote. In order to form a shared understanding of the goals of a new project, we need to be together physically in order to define new working norms. When we are together, we are much better able to pick up what is between the lines, or the multitude of micro-habits that make up the ‘how’ of working together. One definition of culture is the little things we do. There is a scene in the film “A Few Good Men” in which 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, the soldier admits that the mess-hall is.
Aligning in-person collaboration with the product life cycle
When I think about what an office should be for, I think of solving the problem as the main goal. When we have a new team, when we have a new project, or when a project runs for a long time, this is when we must bring people together. We can get away with remote work once the culture is refreshed. If there is 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. The pattern of “one-remote, all-remote” sprung up before the swine flu. 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. The sessions must be designed to promote the formation of teams and working standards.
When a new project starts or a new team is formed is the most obvious time to bring employees together in person. Establishing cultural trust can be achieved by getting the team together for the first week or two. It is exciting to be part of a new effort, which is why software practitioners resist this less than might be expected.
- 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.
It is important to get together to refresh the culture for long-term projects. Over the past six months, I have been surprised more than once when seemingly intractable disagreements that caused serious friction on high-functioning teams seemed to disappear after one offsite. It wasn’t even that a difficult issue was finally solved by deep in-person collaboration, it was that the issue disappeared altogether. It was only a mental block on how teammates understood each other. Teams should be brought together every three months for a week of in-person collaboration, according to my recommendation. It is not obvious to us that making the effort to get together is important for the health of the team and the success of the business. We need a bit of support. I think it’s a good idea to make the ongoing get-togethers 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.
The compromise of management asking employees to come in two or three days a week does not make sense. I would question it in two ways. It brings up an “us and them” dynamic of those who live near enough to an office to come in, and it is harder to maximize a real estate footprint around that. The mandate is too separated 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’s easy for the employee to consider it a less oppressive form of drudgery than five days a week. Without a “why” attached to the work itself, software practitioners quickly become frustrated with what comes to be seen as arbitrary rules.
Software development is more productive and less risky when teams have moments of togetherness. The business need is best satisfied when teams respond quickly to end user needs, which requires 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 ties engineering teams with the business goals.
You can learn more by visiting us here.
