Keeping It Simple for Great Collaboration at Snap! Mobile
Snap! Mobile was founded to help educators fund programs and resources for their students — bringing stakeholders together to work together and meet shared goals.
So it’s no surprise that Snap! Mobile’s internal teams operate on similarly collaborative lines.
For Vice President of Data Science and Insights Philip Garland, this approach is central to the success of his team.
“Our team is wholly dependent on cross-functional communication,” he told Built In Seattle. “In order to have any work at all we must field and solicit research questions from our colleagues.”
Of course, all good communication goes in more than one direction, and Garland and his team are responsible for ensuring that every stakeholder is fully informed.
Our team is wholly dependent on cross-functional communication.”
“Once questions have been asked of our group, we summarize our findings in simple terms and give some measure of data quality that, in turn, affects the confidence in the interpretation of the results,” he said. “All questions or requests need to be translated into specific requirements, and all findings need to be shared. As a result, constant communication is par for the course.”
With these practices, Garland and his team are able to communicate their complex work to non-technical partners while the retaining nuance and meaning needed to make the right decisions for the company and their most important partners: the educational communities at the core of Snap!’s work.
Built In Seattle sat down with Garland to learn more about how his team keeps communication smooth, effective and meaningful across Snap! Raise’s cross-functional teams.
When it comes to updating non-technical stakeholders on your team’s latest efforts, how do you translate the complexities of your work into digestible language?
In order to distill technical jargon into plain concepts, we often use analogies, and metaphors conversationally and also employ graphs, charts, diagrams and illustrations in conjunction with plain language to communicate our points.
Can you share an example of a time when you secured buy-in from non-technical stakeholders? What learning did you take away from that experience?
When testing new products and features, the data science team wants to provide clear causality through random sampling of users and random assignment to the new product test condition. However, sales stakeholders want to hand-pick test users so as to not jeopardize sales relationships. To get buy-in, we tend to demonstrate how different customers might approach the same feature and explain that if hand-picked test users systematically vary along some factor, our results would be skewed, our interpretations would be erroneous and our long-term sales will suffer. In short, we learned to explain how our initiatives affect the bottom line.
