Starting out in Data at Atlassian: What do “soft skills” actually mean?

Picture the scene.

It’s 2019.

Game of Thrones hasn’t yet disappointed a generation.

And, as a math student with a penchant for employment, every career fair in my life is telling me I should become a “data scientist”.

However, the key thing two-years-ago-Max didn’t know was how all the technical stuff — machine learning, statistics, and so on — actually worked inside a business. “Business acumen” and “soft skills” were ideas that made sense, but I had no clue what they meant.

I wrote this for anyone in the same position now. Here are 3 examples of soft skills that I’ve learned more about in my first six months as a data scientist at Atlassian.

Communications skills are much-talked-about but still under-valued by many in the field.

“It’s amazing how much damage four years of studying maths can do to someone’s communication skills.” — one of my stats professors

I remember scoffing at this quote — until I started working at Atlassian, where written communication is super important. The technical exposition of a mathematical proof or academic paper is designed for readers who have lots of time and specialised context for the topic and methods being discussed. This is not the case at work.

For all the other math graduates out there, I cooked up a little formula to convince you:

This formula really highlights the importance of getting buy-in: shifting more time to crafting the exposition of your work has a far larger impact on your impact than bumping your accuracy by another 1%.

There is lots of good advice online for how to improve this skill (check out this great post). Here are a few points that I was surprised to learn at work:

• People like memes at work. Readers are unlikely to forget the moments where they laughed, so humour is a great way to engage them and make sure they remember what you’re saying.
• Takeaways and assumptions are more important than methods. Communication in academia is entirely about explaining your methods — whereas in a business context, you need to be able to explain your methods in detail if needed, but they aren’t usually the focus.
• Kill your darlings. Cutting everything except the one chart you need is a surprisingly rewarding process. It forces you to focus on the key message, and more than a few times I’ve found that it has crystallised my overall approach. 20 charts might be sacrificed, but it will not be in vain.

How long is a rabbit hole?

“I love deadlines. I love the whooshing noise they make as they go by.” — Douglas Adams

Even as a grad, I’ve had to decide which projects I should be prioritising, and when enough is enough. This is surprisingly difficult — but I believe that it’s one of the most under-appreciated ways in which a data scientist adds value.

In any company where lots of people have technical skills, many people can visualise data or create machine learning models. Software engineers commonly do data analysis for investigating reliability issues or cost-sizing.

So what “special sauce” do data scientists bring to the table, asides from just being better at technical data work and communication?

I think that it’s an intuition for how far to pursue a lead, how complex a model to build, and which project or tasks will create the greatest potential business impact.

Here are some examples:

• Drive analysis by a “so what” focus. This means both starting out analyses with a specific business question to answer — and keeping an eye open for any results you find along the way which challenge your assumptions. A challenging side-effect of this is the danger of “discovering” insights that are interesting but simply not true — which is surprisingly easy to do.
• Don’t say yes to everything. One of my team-mates recommended that every time a partner asks me to do a piece of work, I should ask them what they intend to do with it. If analysis doesn’t have a path to impact, it is wasted work — and time is better spent elsewhere.
• You don’t always need to be super accurate. Often we just need to understand whether, effectively, an arrow is going up or down. In these cases, if you believe that your numbers are systematically 10% off in a particular direction, then it’s actually fine — because both the “before” and “after” values are affected similarly.

Both finding and making mistakes is part of the job

“We call them bugs, not mistakes, for a reason” — my manager

Mathematics is a discipline with exactly zero tolerance for error. A proof is either right or wrong. Moreover, you know exactly how to check its correctness.

In data science, the real devil isn’t in the details, it’s in the “unknown unknowns” — the issues you aren’t aware of in the first place. How do you find them? And what do you do when an error slips by?

• It’s tempting to look for errors in your code, but often it’s somewhere else. One of my workmates Rohit investigated an unanticipated drop in a metric following a release. My instinct was to check for errors in SQL queries and statistical tests. But he found that the new code resulted in our analytics being affected by the users’ download speeds — and he found this not by searching through code, but by running around his house, changing the strength of his WiFi connection!
• Reconciling your results against previous work is vital. I was surprised to learn how important checking results against previous work is: for example, if you disaggregate sales by region, the sum total should equal the total sales across all regions. If there’s a difference, either your query or the ‘official’ one is wrong.
• Moving fast means you’ll make mistakes because of “unknown unknowns.” Once, after releasing an important piece of analysis, I found out that the silent failure of a data transformation 2 years before I started had quasi-randomly removed half my data. However, my team has a great perspective of viewing our analytics as an iteratively improving process — similar to the Agile product development framework. Mistakes are bugs because they’re expected to happen and occur as part of the usual process of providing analytics.

Conclusions

These three domains — communicating with others, avoiding unnecessary rabbit holes, and finding and dealing with mistakes — all have one thing in common: they sit at the intersection of technical and “soft skills.” It’s tempting to say that all you need to do is to switch modes depending on the task you’re working on. But I think the examples I’ve shown demonstrate how an integrated approach — rather than a “left brain vs right brain” framework — is needed in each domain. There is no neat divide of tasks into those which require only technical vs those which require only soft skills.

Seeing how others maintain that balance is definitely one of the more interesting things I’ve learned from in my time here so far. I’ve realised how much left there is to learn, and have hopefully 🤞 improved a little bit on these “soft skills”. At least I can say that I was paid to make memes.