5 Ways Working Remotely Changed the Way I Think About Teamwork

For the last three years I’ve been an architect on the Hipchat team working remotely, with the rest of my team working far, far away from me in San Francisco and Austin.

People talk a lot about remote work these days, but as with most things, you never truly know until you’ve experienced it. I’ve learned quite a bit about remote teamwork along the way as an architect and developer. Here are some of the highlights.

1. Put people over product.

In just over a year, my team went from a close, eight-person unit to over a hundred people. That’s a lot of growth in a little time. As more and more people were joining the team, I found myself focusing on the many features that needed to get out the door, instead of training and onboarding new developers (who were basically left to fend for themselves).

As an architect, I should have realized how short-sighted that was. As an Atlassian, I should have realized that our values for teamwork were more important than our code.

Like bad first impressions, on-boarding done poorly can leave lasting damage that takes a long time to repair. On-boarding is about much more than teaching a developer where the source code is located, it is about communicating and living your company values, in our case, “Play as a team” or “Be the change you seek”.

Personally sitting down and working shoulder-to-shoulder with a new team member imparts far more valuable information about your values than a hundred powerpoint presentations. When someone new joins a company, they come with a fairly blank slate for how things work and what is expected from them, so it is essential for them to see a team’s values in action and be given early opportunities to build relationships and contribute value.

Lesson: Let that new feature release slip by a week. Sit down with a new team member and work on something together. Let them see rather than just read about your company’s values. Put aside the inconvenience of traveling for work and make that extra effort to connect with a new team member. The impression you give them, the relationships you build and the sense of purpose you instill will benefit the company far more than one week of coding.

2. Ownership is more important than perfection.

During a particularly busy time at work, my team brought in a bunch of new developers who had a steep learning curve ahead of them. As a developer, I was concerned about the quality and consistency of the code, so I doubled down trying to review and be consulted on every change to the system. I might have been a tad bit overbearing. Looking back, I wish I realized the value of ownership, and how important it is for people to feel like what they’re working on is theirs.

In my world, these types of extra duties might be fixing what’s broken, cleaning up unnecessary elements, taking time to improve the design, or writing documentation. These tasks often aren’t reflected Jira tickets or roadmap plans, but they’re part of the day-to-day work that keeps a codebase clean and flexible.

Without ownership, developers do the absolute minimum required, causing the code base to become a dumping ground for different and often conflicting styles and patterns. And this can have a serious impact on morale when the language, frameworks, or code are unfamiliar. This isn’t about one architecture or another. It’s about onboarding and empowering developers.

Lesson: Approach your code with a DevOps mindset, which encourages giving ownership to others. It is hard to trust someone new with your baby but find a way through onboarding, pairing, frequent trips, or even solving production failures together. Historically, Atlassian has given every developer write access to all products because that was the kind of open, trustworthy culture we wanted to create. If that’s not an option for you, find a non-critical part of the project they can dig into and feel like they own.

3. Define your role clearly.

When I started at Atlassian in 2006, the engineering titles were developer, senior developer, and founder. That was it. Although we’ve grown a lot since then, I like to think of us all as just developers doing whatever is needed to make great products for our customers. But the reality is that as an organization grows, more specialized roles are needed to scale alongside the code and number of customers.

A title is more than an ego boost, it is a way to communicate what you are (and are not) responsible for. Simply telling new folks your title isn’t enough, as it can be interpreted differently with every new person that hears it. Again, getting this wrong can cause long-term damage and be a factor in future disagreements or missed connections. Therefore, not defining your role isn’t about just you. It is about not hurting your team, your project, and ultimately, your customers.

Architect is a title that has traditionally been a source of confusion not just at Atlassian but also in our industry. When I was the second person at Atlassian to receive this title, I figured it just meant a more senior developer, someone outside the normal planning process.

When I became the integration architect, where I had to try to coordinate the activities of the different Atlassian architects, I realized the need to define the job description and I attempted to do so, with mixed results. Even today, that definition seems to be in flux. Regardless, it is especially important that your team is clear about what role you will play, and the sooner that is done, the easier things will be.

Lesson: At the beginning of your tenure and with every onboarding, sit down with team members and talk about what you expect from them, what they should expect from you, and what shouldn’t be expected from either side. It is sometimes more important to discuss what aren’t your responsibilities than what are.

4. Tone matters online.

As nearly all of us have experienced, in-person communication is much different than online communication. And there are even differences in how to communicate in different online contexts. For instance, what tone you take or what words you use in a personal chat or email may, in fact, not be appropriate for a large team chat room.

In a large chat room, you may not have a solid personal relationship with each member, and their impression of you may come solely through chat communication. Chat is such an abbreviated form of human communication without all the nuances of facial expressions, body language, and tone, that the bits the reader fills in the gap may not match your intention. For example, what is meant as a joking, “wtf dude?” could be read by someone that can’t see you as an offensive attack.

To add another layer, what words may be appropriate in one culture aren’t necessarily appropriate in another. For example, from my time working with the US Navy and then later in Sydney, I picked up a habit of swearing like a sailor and telling it like it is. While these habits are well understood by my friends from these groups, another group could take them as wildly inappropriate.

Lesson: Be careful how you communicate in a large chat room. Even if you know each member at the time of the chat, others could read it later and develop an unexpected impression of you that you might not find out until it’s too late. I once heard that remote communication is opt-in, whereas local is opt-out. Make sure they want to opt-in.

5. Remote-friendly is not necessarily remote-first.

Hipchat being a chat application itself, we believe in the concept of remote office collaboration and we are remote-friendly. We operate in three major offices (Sydney, San Francisco, and Austin), and have local and remote workers spread out across at least eight different time zones. Even with the way we live and breathe remote collaboration, there are still gaps between this vision and a true remote-first culture.

One particular perpetrator is the in-person side conversation that comes up between local people over lunch or in the hallway after a meeting. These are great and productive for the people involved, but since they are exclusively local, remote team members can’t voice and represent their views.

If these hallway conversations aren’t communicated in a timely manner they can create a rift in team consensus, and sometimes create lasting hard feelings. Similarly, local people can feel threatened by unexpected or uncommunicated changes initiated by remote folks, and remote workers can be frustrated by decisions made in their absence or personal issues that aren’t communicated in a timely manner. It really is all about communication.

Remote-first teams adopt a structure both for communications and processes that allows each member, regardless of where they live, to be included in major and minor decision making, daily collaboration, and social interactions.

The best example I can think of is from my time at the Apache Software Foundation. In ASF projects, every single decision had to be proposed and approved on the single developer mailing list. This process took a lot longer than putting 10 people in a room for two hours, but it leveled the playing field for all team members.

Lesson: Be very cognizant of the culture of the team you join as a remote employee. Find a way to create a remote-first team of remote or remote-friendly workers that can own a project and its execution independently. Failing that, ensure all decisions are made transparently and include remote workers as appropriate, leveraging time zone-friendly online tools and processes.

Minimize the number of remote relationships that you need to create and maintain to do your job, and don’t think that knowing a few key folks in a remote office is enough. Be aggressive in identifying and reaching out one-on-one with remote team members that may disagree with your proposals; don’t wait to be told that there is dissension as it’ll be far too late.

Final thoughts

As my experience has shown me, being an architect is about so much more than code, frameworks, or system design—it’s about people and teams. If you are hired on a team, you are technically qualified to be there. What is less obvious, and admittedly more difficult to remember, is the importance of the non-technical bits. There seems to be a happy medium between getting shit done and singing kumbaya around the fire. While I’m still figuring out where the right balance is, I’ve learned that focusing on the long-term is much more impactful than getting bogged down in the details of the short-term.

This article was originally published on The Atlassian blog and republished with permission.