Marketo Retrospective Part 3
As part of a series, I am doing retrospective lessons from my 9 years at Marketo. I learned alot of things and this is my way of processing all of that experience into bite-sized nuggets of wisdom. Today, here is what I learned about remote offices.
Marketo had many sales offices around the country and even around the world. After a certain amount of people, it totally makes sense to distribute. It’s much better to close a deal in Australia if you actually live down under. Having centralized sales may be useful to some, but I clearly saw the benefit. The downside is that it is incredibly hard to teach the remote offices about new features and make sure they are demonstrating the product effectively.
Services and Support Offices
This is actually one of the best uses of a remote office. These are generally lower paid employees and going to a less expensive location saves money and gives a better quality of life to the employees. It’s easier to learn new features because you are living in it all day. Additionally, you can provide more hours of support if you have offices around the different time zones. Ireland and Portland were especially effective support locations.
I wish I had talked more with the people in Ireland. I think they wanted to talk with me more, but the time zone difference made it really hard. I would call the office a success, but it also lacked many benefits you get from working closer.
This is the one that most Silicon Valley companies struggle with. If you have a blackbox situation then India or Eastern Europe is an option. You need a rock-solid specification or you will end up with something weird.
Blackbox engineering situations is when you need something built that does not have any knowledge of the rest of the system. Also, the rest of the system doesn’t need to know how the blackbox works. It just does a simple job. Thus, it is easier to outsource because the communication requirements are lower.
I have worked with great engineers and poor ones in all parts of the world. I feel like there is a formula that has something to do with:
- Q = Quality of engineer
- D = Number of time zones distant
- C = Complexity/Length of project
The point is that remote workers create challenges that onsite workers do not. You can still be successful with a remote worker. I worked on a project with a superstar from Amsterdam named Ian. If he was a lesser engineer, then the project would have taken twice as long. I also worked on the Marketo community version 3 (its currently version 4) with a team in India. That one did not go as well, because the talent wasn’t as good AND the number of time zones distant was too many.
There was also a Portland team of engineers that were actually a delight to work with. This had alot to do with the head of that office (Shaun K) who was such a great leader and communicator that it just made things go better. The fact that they were in the same time zone helped tremendously. They (or I) could fly and visit often.
In Silicon Valley, engineers are highly recruited. Google, Apple, Facebook, Box, Uber and others all try to recruit a limit set of engineers. It’s hard to be a startup and get the best. However, in Portland or Seattle you can be a bigger fish in the pond. Creating a remote engineering site makes sense for economic reasons, but you need to create extra communication channels for PMs and Designers to talk. Specifically, I found video conferencing to be a great bridge between different locations.
The pool of talent in the Bay Area for a mid-level tech company that has already gone public is fairly small. This led to an erosion of talent in the San Mateo office. Realistically, unless you are prepared to compete with the perks Google doles out, a remote office may be a better option.
In the end, I think remote offices are a reality if you want to scale. You just can’t have everyone in the same room forever. The lesson I learned was to over-invest in communication vehicles like video conferencing, tele-presence and Slack. Also fly people in both directions frequently. Also, I would try as long as you can to keep the engineering teams in the same time zone.
When I started this post, I thought I had alot of good learnings, but here I am at the end, and I think I have very few concrete suggestions. Something for me to think about, I guess.