The recent backtracking of Google, Amazon, and Apple on remote work is fascinating. For companies that are supposed to be on the bleeding edge of corporate governance, the decisions that these folks made not to allow remote work was one that makes me want to ask – “show me your work that leads to your decisions.”
In that spirit, let me show mine.
In 1994, Andries Van Dam got in front of an undergraduate computer science class and announced that the idea of all software engineering remaining in the USA was foolish. As software became more about composing components than building everything from scratch, and because any software engineer anywhere can construct a component that any other engineer could use, jobs would be offshored. In effect, he argued that there would be fewer jobs in the USA.
It’s easy to laugh at Andy now. But in 1994, the bulk of software was for military-industrial uses. The worldwide web had not yet come into existence. And thanks to the Peace-Dividend, jobs were being lost everywhere in tech.
Many years later, he and I caught up, and we remarked that he was right; what he didn’t account for was an ever-increasing pie. In other words, both statements could be true; global teams delivering components would happen, and more jobs writing software would exist.
Post-dot-com boom, the fetish in the tech industry was this concept call off-shoring. The thesis was that companies could find good enough talent at lower cost-locales and thus reduce their costs.
I remember being in a meeting where some GMs declared that we would only be hiring in India, convinced me that Andy’s apocalyptic vision was right, and plan for a backup plan for my software career.
Waiting on a Green Card and having no other realistic choice as the nuclear winter of 2001-2009 took hold in the tech space, I had to learn how to work with remote teams.
In 2002, I made my first recruiting trip to India, where we brought up a team whose job was to take on NetCache. It was really a case of training my replacements. Being young and foolish, I don’t think I really understood what was going on, but it was pretty grim.
In 2003, I had another GM show up in a meeting and explained that we needed to offshore more work to India, and my project on storage management was to be sent to India.
But then something funny happened.
We started hiring in the USA again.
And then we acquired other companies in other parts of the USA.
And then, I suddenly found myself leading teams in Bangalore, Palo Alto, North Carolina, and Pittsburgh.
At one point, I was on a project where everyone was remote, and I wondered why the heck I was coming into work?
From about 2004-2009, every meeting had someone dialing in remotely. Every project had a remote engineering team.
Then I moved to Zynga, and I swore I would never work with remote teams again, and yep, I was working with teams all over the world.
Then I arrived at VMware in 2015, where remote work had not been widely adopted across the company.
But then, from 2015 to 2019, my partner in crime and I decided, that talent not location, mattered. So we hired folks anywhere. Our architect for our biggest technical achievement was on an island in Puget Sound, and the other one is in Humboldt county.
The location didn’t matter. We would hire anyone anywhere.
After the Heptio acquisition, I remember talking to some VP, and he said – “well, it’s going to be hard to meet because the Heptio folks aren’t in PA.” And I was like, “oh, if they were, that would suck because the guy they need to talk to is in Humboldt county and a beach house in Washington State.”
If I looked at my team, I had tech leads in Bangalore, Austin, Washington State, Sofia (Bulgaria), and Humboldt county.
We succeeded as a team because we didn’t care where you lived. And we figured out how to work together even if we didn’t have physical proximity.
And so over 17 years, I have been working with remote teams, and those teams have delivered staggering business value across three different companies and three different industries, including a hardware company.
The idea that remote work is worse than local work is a failure of the imagination of business leaders and management leaders.
But why?
Because here’s what I learned, if X units of work need to get done, and individual Y wants to do them in location Z, then X units of work get done if you let them do it from location Z. If you don’t, the X units of work don’t get done until you find individual i in the desired location R.
So the loss of productivity is measured in the following way:
For everyday d that some engineer E is not working, X units per work per day (x/d) do not get done, or P(E) = x/d
If D(i) is the number of days that it takes to find the imaginary i, then the lost productivity is P(i) = x/d*D(i)
If time to market matters, and days are precious, then the value of the lost days is huge.
So when I hear leaders tell me that agility matters, speed matters, and they are unwilling to let people work from where I must admit, I have a hard time believing their math. And like my wife, who is a math teacher, says, I want to say – “show me your work.”
But then I hear startups or small teams say, but small teams.
And that got me thinking.
In 2003, when my team was only 8 engineers, we hired a team in Bangalore.
In 2010, when Zynga was growing, I couldn’t get recruiting to give me the time of day. I had 5 engineers in San Francisco, and the Chief People Officer, Colleen McCreary, asked if I was willing to hire in Seattle. And so we grew that 5 person team very quickly, and they built the infrastructure that Zynga used over the next decade.
In 2015, when hiring was very hard at VMware, I had nobody in Seattle, and when a very senior engineer showed up, and others were wondering how to make him productive, I said – yes.
Every single time, finding talent was the hard part. Dealing with remote locations was easy. And then, because I was willing to go to remote locations, finding more talent became easier.
Talent matters. Location doesn’t.
And that leads me to the following conclusion – if you can’t work with remote teams, then you might want to look very carefully at how your team works.
Leave a Reply