Tell me about a time when the diversity in your team helped you ship a better software product.
An interviewer at a large software company asked me this recently. I hadn’t anticipated this question but I managed to improvise an answer.
In my mind I was comparing the team I was a part of in Facebook for 4 years with the teams I had worked in previously in India. I said something like - in India our hiring processes were biased in favour of people who spoke English fluently. The software I worked on was available exclusively in English, even though most Indians don’t speak English fluently. None of us felt the pain of using software that was in an unfamiliar language, so we didn’t push to localise it.
Realising that I had answered the complement of the question the interviewer had asked, I pivoted. I pointed out that at Facebook, teams are more geographically diverse. The first team I joined had folks from all parts of Europe, Asia and South America. Often we would have labelling exercises where we had to determine if some publicly posted content was “fake” or not. Software translators didn’t understand cultural or situational context but having team members in the room who understood that context helped us make better decisions.
On Second Thought
I thought about it more afterwards. I think the Facebook example was fine. But the Indian example lacked nuance.
The interview process was biased towards English speakers, but I’m not sure an India based team can choose differently. If you want to hire the best team, it makes sense to maintain an open and welcoming environment to folks from all over the country. The team has to choose a common language and stick to it for all technical discussions. That way team members who might speak Hindi, Tamil, Punjabi, Gujarati, Telugu or Marathi can work effectively with each other. We missed out on great people who didn’t speak English, but I think it helped the team in the long run.
People spoke in their first language for casual conversations, but that wasn’t a big deal IMO. I say that even as someone who can only understand Hindi, not speak it. The important thing was that no one felt excluded from contributing to technical conversations because of a language barrier.
As for localisation of the software - there was reason we didn’t do that. The first iteration of the app targeted English speaking office workers using the app for tax benefits. Localising the app wouldn’t have expanded the potential audience. This approach worked for the company, and it later became a unicorn.
So while the hiring system was biased against a specific group, it might have been the right call in retrospect. Ideally we’d compare with teams that didn’t have an English requirement in their hiring pipeline, but I don’t know of any Indian engineering teams that didn’t.
Hardware diversity
There was something I felt I didn’t do well. Not others, but me personally when I was developing the Android app. I always used the best phones on the market. The ones with the large screens, ample RAM and plenty of processing power. Worst of all, I was always on Wi-Fi. In 2021, 4G covers all of India. In 2014, even 3G scarce. Many folks had to make do with 2G. Developing on Wi-Fi meant I never understood how poorly it performed on weak connections. I’d experience it on my commute, sure. But not to the point where I pushed for us to fix this and reach parity with WhatsApp, the gold standard for an app that performs on low connectivity.
This is a problem at Facebook as well. Early feedback from employees is critical to iron out issues before they reach production. But most employees use iPhones or Android flagships (Pixel, Galaxy) and no one’s phone is older than 2 years. If there is an issue that only affects users with small screens, it will not be caught by employee dogfooding.
In fairness, Facebook also had a program at one time where employees could opt in to degrade their connection to 2G quality one day a week. I don’t know how much that helped, but it was the right idea.
We can do better
Diverse teams help you understand some of the problems that your users might be facing. But not all. Understanding the perspective of users on low power hardware and poor connectivity will always be a challenge for software companies. A diverse team might still use MacBooks and iPhones that bear little resemblance to hardware used by regular folks.
It’s unrealistic to ask employees to replace their devices with older/inexpensive ones. But it is possible to account for this disparity by
- Writing automated tests that run on all manner of devices. These tests could take screenshots and make sure no regressions have happened on smaller screens.
- Keeping a stable of older devices with less RAM, CPU and smaller screens. Test on these devices before releases. Use these devices for development sometimes instead of always relying on the simulator or primary device.
- Tracking load times and other important metrics from real world users, while preserving their privacy. Take care to interpret these correctly though. As a team at Google found, improving latency increased the average latency seen by users because previously excluded users were now using it. That’s a win, even if it doesn’t appear to be at first.
- Speaking to users of your app outside your bubble. Ask them what they want from your product, and watch them as they try to use it. You might find that your interface isn’t as intuitive or performance is worse than you thought.
Many teams (like WhatsApp) have identified this issue, fixed it and reaped the benefits. All engineering orgs can learn from that.
Thanks to Samhan Salahuddin and Tom Weightman for reading drafts of this and suggesting improvements.