I’m a big proponent of remote work and geo-distributed teams. During my 4.5 years at SAP Concur, I had the pleasure of working in an environment where we could foster remote work and invest in our remote-friendly culture. We had engineers from Prague to Palo Alto, with a healthy combination of folks working in our global offices and folks working from home. We successfully built a group culture that enabled remote team members to succeed, but it didn’t come easily.
I previously wrote about fostering remote work, where I detailed my own journey into a remote-friendly culture. In that post, I described some tips we learned at Concur that I wanted to share. The post fell short of describing how we transformed our culture to get to that point though, instead mostly highlighting the tools we used.
While I no longer work at SAP Concur (I returned to Microsoft in December 2019), I will always be proud of what the UI Engineering group at SAP Concur accomplished with regard to becoming remote-friendly.
Searching for Remote-Friendly Job Openings
I recently saw a tweet criticizing a job opening where the employer stated that they were hiring local, or “remote for the right candidate.” That phrase can understandably evoke some doubt or frustration.
- I’m remote; would I be the right candidate?
- Why do some people get preferential treatment to be able to work from home?
- Is this just a carrot on a stick, where I’ll think I could work remote but you’ll later tell me I need to relocate?
- Is this just a face-saving tactic so you can look like you’re remote-friendly when you’re actually not?
Many employers have caught on that remote-friendly workplaces will be a big part of our industry’s future. There have been quite a few pioneers who have helped prove this out, there are lots of companies who are making good progress, but most companies still have a long way to go. It’s difficult to narrow job searches down to openings that are truly remote-friendly and assess where the company is in their journey.
Multi-Year Culture Shift
Transforming a group’s culture into one that fosters remote work is not an easy task. You can’t just start hiring remote people and expect everything to work out. And remote candidates shouldn’t expect any company to just hire remote engineers and expect to them to thrive. No, developing that culture must be an intentional investment that itself is engineered–it must be planned, invested in, learned, and hardened.
When I saw Dave Glick’s tweet, I realized that I had not told the story of how we embarked upon the multi-year culture shift at SAP Concur. I recognized the disdain for the words “remote for the right candidate,” and I knew that I’d used that phrase as a fundamental part of our strategy to become geo-distributed. Hence, I was inspired to share my story on twitter, which I’m sharing again below.
This story captures my experience at SAP Concur where I joined to help build out a UI Engineering group. Over 4.5 years, we went from having a very small team focused in Bellevue, WA to having a group of over 60 engineers across many teams all contributing to our UI Engineering efforts. We had teams in offices in Bellevue, WA; Prague, CZ; Palo Alto, CA; Vancouver, BC; and people working from home in Virginia; New York; Minnesota; Texas; California; Iowa; Washington; Colorado; Arizona; Wisconsin; Maryland; Ontario; and Nova Scotia.
My Journey at SAP Concur
The twitter thread started from Dave Glick’s tweet about the phase “remote for the right candidate.”
I don’t really understand “remote for the right candidate” - either the team is remote-friendly or it’s not. Doing a good job of supporting remotes is kinda an all-in thing. I’d guess remote as a fringe benefit, but only for someone you really want doesn’t serve anyone that well.
— Dave Glick (@daveaglick) December 21, 2019
I’ve been in that boat as a hiring manager. I’ll share my story from SAP Concur to help shed some (positive) light on the situation, @daveaglick. (1/13)
When our group was beginning to grow, we knew we needed to foster a remote culture to succeed over time. But the group was young and most of us were new to the company. Only a few folks had experience with distributed teams, and none of us had felt truly successful with it. (2/13)
We wanted a sustainable approach for our remote culture, and that meant we needed to be confident that we could help remote folks succeed. I didn’t want our group’s shortcomings to reflect poorly on a remote engineer or lead them to be unhappy or isolated (and leave). (3/13)
We needed to build a local culture that was ready to be good hosts, and hire the “right” remote folks to seed the group and patiently teach us how to be good hosts. (4/13)
For a long time, we wouldn’t be someone’s first remote employer. With that rule of thumb to quickly identify the “right” candidates, we hired several remote folks while hiring lots of local junior engineers. We began learning the remote culture through a growth mindset. (5/13)
We gave ourselves a couple years to get good at it. Remote folks were succeeding just as much as local folks. We were off to a good start.
Then we started breaking our “never be the first remote employer” rule “for the right candidates.” (6/13)
After a while like that, we really felt confident in our group’s ability to host just about any remote team member. That’s when I wrote this post: https://jeffhandley.com/2018-10-21/fostering-remote-work (7/13)
Then we started hiring some junior engineers as remote. And we started promoting remote engineers into management, and recruiting more aggressively remote than local. We had built a full team in Europe. And we hired in Canada. (8/13)
And then through a reorg, our group expanded into Vancouver and Palo Alto and it was no big deal. The folks joining us were afraid of being isolated, but by then we were taking the distributed culture for granted because we no longer even thought about it. (9/13)
I believe @SAPConcur’s UI Engineering group became a model for distributed teams that I’ll forever be proud of. But if we had hired the “wrong” remote candidates when we were starting, we would have stunted our growth and lost great talent along the way. (10/13)
Like software, a distributed team culture requires a good foundational architecture. It doesn’t succeed by accident, and it won’t happen easily by just hiring folks remotely. You must grow the skill into the culture intentionally, and it won’t happen overnight. (11/13)
Poor results from or attrition of remote engineers could likely lead to executive distrust of the remote culture, so the stakes are high. Many groups will only get one chance at becoming remote-friendly. (12/13)
So if you see “remote for the right candidate,” I hope you’ll see that as a sign of awareness and growth. They have to start somewhere, and hopefully that’s with the right candidates to help them learn and grow and build a sustainable remote culture. (13/13)
Indicators of Success
There are several traits of our group’s culture that told me we had succeeded in building a remote-friendly culture. When looking for a remote-friendly employer, you might be able to ask questions to assess if their culture has gotten to this point as well.
- What local folks do when they need to work from home
- If there are geo-distributed engineering offices (not just sales offices)
- What pro-tips they have for using their teleconferencing tools
- If there are remote engineers at all levels
- How necessary it is for remote engineers to visit offices
- If there are any remote managers
And of course, job openings declaring “remote for the right candidate” is also a tell. That phrase means that the company isn’t truly remote-friendly yet. They might be embarking upon the journey, or they might just be trying to save face–the only way to know is to ask where they are on the road to geo-distribution and how you might be able to help.