Kripa Krishnan
Senior director of Cloud and technical infrastructure programs, Google Cloud
Google
120,000 employees
Preeti Somal
VP of engineering
HashiCorp
1,000+ employees
Liz Ojukwu
Engineering manager
InVision
600 employees
Jean Hsu
VP of engineering
Range
13 employees
How would you describe your organization’s remote ethos?
As a large, global company with distributed sites, we strive to be collaborative across geographical boundaries—remote work has always been in our DNA.
— Kripa Krishnan, Google Cloud
We are a remote-friendly organization. (Pre-COVID, 85 percent of our employees and 100 percent of our engineering organization were remote.) We were built with a strong emphasis on asynchronous work patterns driving our processes and workflows, so scaling the organization was fairly natural. We’re diligent about writing things down and communicating broadly: We believe that if more than two people need to know something, we should write it down.
— Preeti Somal, HashiCorp
InVision was set up to be fully distributed from the beginning. At the time, it was a “crazy idea.” Now we have the tools and the processes to help other teams that are struggling. After almost 10 years, we know how to avoid the pitfalls.
— Liz Ojukwu, InVision
Remote first. We previously had a San Francisco office but are currently office-less. We may have another office post-COVID, but people will be able to choose whether they want to come in most of the time, a few days a week, or rarely (regardless of their role or location).
— Jean Hsu, Range
How do you make major technical decisions remotely?
We’ve always been a distributed workforce, so decision making in remote environments is second nature. I’ve found that decision making tends to be less ad hoc when everyone is distributed—we have to intentionally come together to make technical decisions and not make them on the fly in hallways.
We also work with our customers to make technical decisions that serve them. In some ways, remote work removes communication barriers in working with customers: Customers are increasingly adopting online collaboration tools, which makes it easier for us to engage on a more consistent basis—almost as if we’re extensions of each other’s workforces. We don’t have to save conversations for in-person meetings. This has been especially helpful as our customers look to us for best practices and support in the current environment, as many have moved to remote work overnight.
— Kripa Krishnan, Google Cloud
All our major technical decisions are made remotely. We write down everything (did I mention that already?), and we author RFCs for all major technical decisions. These are emailed to an alias that anyone in the company can subscribe to (have I mentioned transparency yet?). We also have a document that describes the RFC process, as well as how to write an effective RFC to make sure employees can be successful with our culture of asynchronous communication.
— Preeti Somal, HashiCorp
As a fully distributed company, we make all of our decisions remotely, and sometimes asynchronously. We strive to create an environment where all impacted parties have the opportunity to share their perspectives without having to attend a meeting in order to move ideas forward. This makes documentation paramount.
We often use the DACI (driver, approver, contributor, informed) framework to structure process and document decisions, which ensures clearly delineated responsibilities for those involved, a set timeline for finalizing the decision, and a record of the options that were considered. Sometimes decisions are made through comments on a DACI document, or the DACI is brought to our engineering architecture group for feedback before a final determination is made.
When technical decisions involve working through problems that co-located teams would typically whiteboard, we use Freehand, a virtual whiteboard tool we built for visual communication. In Freehand, we can work collaboratively to visualize ideas, give immediate feedback, and quickly illustrate concepts that might be hard to describe with words alone.
— Liz Ojukwu, InVision
We rely heavily on our product, Range, to help out. (Range is a tool that helps teams work better together with daily check-ins by team members.) We append designated Range “flags”—such as [fyi], [blocked], or [feedback]—to check-in items to make sure discussion topics and design docs get the right eyes on them.
Later in the process, someone may share a structured design doc that covers goals, non-goals, other options considered, the proposed option, different phases, rollout plans, risks, etc. That person then adds that doc to their next daily Range check-in with the [feedback] flag so it gets elevated for review at the next “collab” meeting.
Compared to an in-person whiteboard chat or similar, the process requires more planning and forethought, but the end result is more thought through—which saves engineering time—and it gives others more of a chance to review and provide feedback. It also generates written documentation, which is useful long term for context.
— Jean Hsu, Range
How do you handle remote incident response and management?
Google SREs are trained to work across great distances. Our SRE teams have historically been split between two or more locations to deliver 24/7 coverage and to have necessary redundancy. We also have a tradition of preparing for the unexpected, such as through our annual disaster recovery testing exercises, which involve simulating and working through worst-case scenarios.
In cases where hands-on work is still required, like in our data centers, we have split our staff into multiple teams that rotate (helpful for minimizing COVID exposure, as well). Google Glass has helped us eliminate the need for travel: When we need a specialized engineer to install or fix certain hardware, they can guide an on-site technician fully remotely.
— Kripa Krishnan, Google Cloud
We have a well-defined on-call program and incident management and response processes. These include things like the creation of incident-specific Slack channels and document spaces. Given that we are well versed in remote work, this is pretty natural for us.
— Preeti Somal, HashiCorp
When an incident occurs, we use Slack, PagerDuty, Zoom, and a well-documented incident management process to quickly gather the right people to assess and resolve what’s gone wrong. Our support and engineering teams have accurate expectations of each other so that we can devote attention to the incident at hand. In a typical incident, an incident commander directs the engineering response and communicates relevant details to the support team, who can in turn relay updates to customers. We have a culture of continuous improvement, so after ensuring the customer impact is remedied, we reflect on the cause of the incident to ensure we don’t run into the same problem again.
— Liz Ojukwu, InVision
Engineers take on weeklong on-call shifts to respond to any incidents. Incident response is often remote to begin with, with engineers responding to alerts from home on the weekends and in the middle of the night. We lean on on-call playbooks and documented knowledge, with clear escalation paths.
— Jean Hsu, Range
What do you do to avoid silos?
When we’re all remote, team members may lose the ability to course correct with their work in real time. So we lean more heavily on existing collaboration tools and try to follow norms with rigor. This includes having clearly articulated goals for teams, daily stand-ups to check on progress between them, regular team meetings to share information, and clear meeting norms. We also make sure we have clear handoffs, especially when traversing time zones.
It would also serve managers and leads well to find avenues to network with “neighboring” teams (partners, dependent teams, etc.) to communicate roadmaps, progress on efforts, or work together to resolve any dependencies between the teams. This creates a shared understanding of efforts between organizations as opposed to just within organizations.
— Kripa Krishnan, Google Cloud
We have best practices across all levels of the organization. We’re structured along the notion of “workstreams,” which are composed of all the individuals who need to collaborate most effectively toward the delivery of a feature or project. For example, a particular engineering team, engineering manager, product manager, design lead, or education engineer might be a unit. Each workstream has its ceremonies and cadence of operating cohesively, including events like release celebrations and team-building exercises. Pre-COVID, this team would organize an in-the-same-physical-space offsite once or twice a year; now we’re seeing creative online events becoming popular.
At the highest level—that is, across all of engineering—we have weekly all-hands meetings that rotate through topics, from deep dives into secure software development practices to teams showcasing their most recent projects.
— Preeti Somal, HashiCorp
One thing InVision does well is design processes that ensure collaboration at each step. Our product, design, and engineering teams work closely throughout the ideation and planning process. We have biweekly company all-hands meetings, and a monthly department-level all hands where we celebrate wins and update the teams on the progress against our goals.
On the engineering side, we share the responsibilities of code reviews and frequently collaborate on technical specs and diagrams using Freehand to support shared understanding. Our code repos and documentation are accessible to everyone within engineering. We use tools like GitHub, Jira, Confluence, InVision, and Freehand to collaborate on product briefs, UX design artifacts, and technical specs, which creates an easily accessible knowledge base.
— Liz Ojukwu, InVision
We’ve really leaned into using Range—we’re our own best customers!—to keep the team connected and aligned. Each day, Range rolls up everyone’s check-ins into a report, so we can stay in sync on and across teams. We also track company-level objectives in Range and review them during weekly team briefings.
To build in a social layer, we schedule optional activities during work hours so that remote interactions aren’t limited to people you work closely with. We’ve experimented with asynchronous events for things that are usually synchronous—for example, after a launch, we had an asynchronous retro, and we recently had an asynchronous team offsite to create a team zine.
— Jean Hsu, Range
How do you ensure visibility and career growth opportunities for remote team members?
It’s really important for managers to allocate more time than they may in a co-located environment to understanding the work their teams are doing, so that they can advocate for their work and bring new projects to the team. They can also play a role in communicating the work of their teams to peer and/or dependency teams to make sure they’re still able to collaborate effectively on larger efforts in other areas of the organization. This type of “networking” with other leads also helps uncover new cross-functional projects that managers can bring back to their teams as career growth opportunities.
— Kripa Krishnan, Google Cloud
We have a career matrix and have recently put together a readme that helps team members and managers think about career growth opportunities. We also have a performance assessment milestone every six months, and our engineering management norm is weekly team member 1:1s.
Historically, we have been a somewhat understated engineering culture; we’re working on being deliberate in our efforts to celebrate achievements at both the individual and team levels. Currently, the primary forums for visibility are all-hands meetings, some of our larger Slack channels, and GitHub. We have a strong open-source focus, and our engineers gain visibility with the work they do in our practitioner community.
— Preeti Somal, HashiCorp
Ensuring visibility into all of the great things engineers are doing is particularly important, especially in a remote organization. One thing we do is create videos that introduce new features to the broader organization. They’re a cross-functional operation, including engineers, designers, and product managers. Another way we ensure visibility is to encourage engineers to write up internal blog posts about interesting problems they’ve worked on, so they can share their knowledge and get recognition for their work.
We implemented role profiles clearly describing expectations at each career level, and team members work with their managers to ensure they have the right opportunities and mentorship available to grow to meet those expectations. We also provide subscriptions to relevant content for continued independent learning, and invite team members to seek feedback and mentorship from our senior engineering staff.
— Liz Ojukwu, InVision
No surprise, Range itself is the default place where we share what we’re working on, align on team goals and objectives, and celebrate successes. We also rely heavily on other asynchronous modes of communication such as shared docs. In a way, a fully remote team (with the right tooling) evens the playing field because you don’t have the issue of people in the office having more context or visibility. In a hybrid setting, we make sure we’re thoughtful and disciplined in our processes so that remote team members are not at a disadvantage.
— Jean Hsu, Range
What advice do you have for newly remote teams?
Shared accountability is at the core of how Google approaches work. This collaborative, symbiotic approach not only accelerates our business strategy and how we work with customers and partners, but also makes Google a great place to work.
With over 100,000 Googlers in offices around the world, one of the best ways to reinforce our culture is in smaller communities (like our product areas or within different regions or offices) where people have a shared sense of belonging, togetherness, identity, and trusted context. We’re continuing to establish new opportunities for Googlers to have more substantive and richer conversations in smaller groups.
— Kripa Krishnan, Google Cloud
Embrace it fully. Often, change isn’t fully initiated because it’s seen as incremental or temporary. Take the time to understand the benefits of being remote, as well as the drawbacks and what’s lost. Build processes to compensate for the losses and accentuate the benefits.
The two Ts—transparency and trust—are critical.
Check in often. Social isolation is real. Ensuring that engineering managers are checking in on employees regularly is essential.
And the rule of two or more: If more than two people need to be aware of something, write it down and communicate it more broadly.
— Preeti Somal, HashiCorp
As Jony Jeyaratnam, our senior director of engineering, says:
The most critical thing for building an inclusive remote culture is to be remote first. Ensure all rituals are designed to support remote team members. This starts with accounting for time zone differences, ensuring everyone can be on video calls, having conversations in channels (rather than DMs), and making any documentation and code as open as possible. This fosters an open environment, which is crucial to a successful remote team.
Also, trust your employees to manage their time and set expectations based on outcomes. Flexibility and trust creates a sense of co-ownership that’s required for employees to stay motivated and deliver results.
Be deliberate about building culture and celebrating together. As a manager, it’s important to consciously encourage collaboration to ensure engineers consider themselves a part of the overall cross-functional team—and that should happen from day one.
— Liz Ojukwu, InVision
It’s completely different to intentionally create a remote culture from the start than it is to be forced to go remote because of a global pandemic. When you read about remote best practices, think through if it’s going to be a good fit for your team, and consider how much change people can handle all at once.
With that in mind, be prepared to reevaluate your processes, no matter how established. Start to move more of your workflow (especially status updates) to asynchronous or semi-synchronous modes of communication, so that you can use limited synchronous phone or video calls for decision making or relationship building. Be flexible and embrace experimentation as a way to try out new processes without committing indefinitely. To support rapid experimentation, document the current state of remote practices. And make it a shared, living document that everyone can contribute to.
— Jean Hsu, Range