3 Principles to Foster Great Teamwork
Proekspert’s analyst Andrus Kuus shares stories about being a successful team leader at North Star conference.
When Proekspert’s Andrus Kuus got up to speak at this year’s Northstar AI conference in Tallinn, he entertained the audience with an inventive speech. Having worked in the software industry for over 23 years, Kuus drew on his many experiences—including that of being an analyst at Proekspert—and shared some important insights on teamwork and project management.
“Today I will tell you three stories about the principles I follow in my work,” he began. “I believe that these principles are also relevant in the field of data science. So let’s start.”
Teamwork does not get better by itself.
Kuus’ first story was about his uncle, a woodworker. He explained that his uncle creates unique furniture, and rarely has a waitlist shorter than 6 months. In other words, he’s a busy guy who often has to reject new work because he feels he cannot deliver results within a reasonable timeframe. This uncle, explained Kuus, also has a son who occasionally helps him build furniture. Generally, it makes complete sense for the two of them to collaborate and share the workload. However, they don’t do this often.
When Kuus asked his uncle why, he was told that the two men have different work-styles that do not mesh well. His uncle gets frustrated when he has to work with his son because suddenly his tools are misplaced, the tempo of the work is different, and the two have trouble agreeing on creative decisions.
Why is this relevant?
Kuus said that it is quite safe to assume that within a few years those attending the conference might be working in a team of data scientists. It also quite safe to assume that a lot of their teammates will be people fresh out of university who really don’t have much experience working in a team.
“If you don’t want to end up in a situation like my uncle,” said Kuus, “you have to deal with that problem.” He also went on to say that the first thing that needs to happen is for you to acknowledge that teamwork does not get better by itself. Somebody else cannot solve the problem for you. As it turns out, as a team lead, you have to deliberately spend time on improving the way you work together. To accept this responsibility is an important step.
You need to make a habit of discussing why and how you do things in your team.
Strive for clarity in communication
Kuus’ second story was drawn from his own work experience. In the beginning of the 2000s his team had to take over the development of a system that calculated bonuses for the customers of a large company.
As is usual in these cases, there was a set of project assets that was handed over to the new team. The most important of these assets was the source code, which in this case came from a corporate workstation.
“When we got access to the computer we found the code,” said Kuus. “In fact, we found several versions of source code located in different folders. It was unclear which one of these we have to use. Soon we found out that there was also another workstation that contained code. So eventually we had 7 different folders containing 7 versions of the code.”
Kuus said that the team tried everything. They analysed the code, ran comparative tests, cross referenced the documentation. Unfortunately, it turned out that none of these folders contained the code that was running in the live system. “So we did something quite unusual,” he explained. “We patched the sources together from the content of several folders and added code that we got from decompiling the live system. This code was our best guess. And fortunately it worked!”
This project was no small task, explained Kuus. It took weeks of hard work and brainstorming. He then referenced a quote from Martin Fowler: “Any fool can write code that a computer can understand. Good programmers write code that humans understand.” This principle applies to more than just writing code, argued Kuus. “Strive to make all your work understandable to other people.”
The moral of this story: choose the tools and practices that help you achieve clarity and understandability. Refuse to use the tools and practices that make it harder.
To keep track of things, Kuus recommended using a task management system instead of Excel sheets sent over email. Choose wiki to store documentation and knowledge instead of Word documents that are hard to update. Choose version control over creating multiple copies of folders on corporate workstations. It is important to have clarity of mind when identifying your tools and processes.
Data scientists talk to data?
The final story of Kuus’ presentation—incidentally taking place very close to the lunch hour—had to do with food. “I seldom watch TV nowadays,” said Kuus, “but for some reason it seems like every time I turn on the TV I always end up watching this cooking show called Masterchef. Yes, the one with Gordon Ramsay as one of the judges.” Kuus explained that often the contestants on this show have to cook food using really strange ingredients like testicles, chicken feet, or something similarly obscure.
During one episode in particular, one of the contestants, a girl named Diana, was struggling with tripe, a part of an animal’s stomach. Like any average person, Kuus explained, Diana had never cooked tripe before. Nevertheless she had to do something, so she improvised.
She did her best, and within 45 minutes produced a nice looking menudo from it. For clarification, menudo is a spicy mexican soup made of tripe and corn tomatoes. According to Wikipedia, this dish normally takes from 4 to 7 hours to prepare. However, Diana tried to make it in 45 minutes.
“I believe that it comes as no surprise that the first thing Gordon said after tasting the dish was ‘I’ve got some raw tripe here,’’ said Kuus. Consequently, Diana had to admit that she had cut some corners and had therefore failed. Of course this created drama, and Diana was not made the next Masterchef.
“But why am I talking about a TV show?” asked Kuus. “Because you and I are living lives that are sometimes very similar to a TV show.”
We often do things that we have not done before, said Kuus. We usually do these things under time constraints and pressure, and often with limited information at our disposal. But unlike the TV show, where the ability to validate ideas has been artificially limited, in real life we can ask questions and validate our ideas.
“In my experience,” said Kuus, “ we tend not to use this ability and just improvise.” Maybe this happens because we’re afraid to look stupid, or maybe we do not want to bother people. “I don’t know. But the latest Kaggle survey shows that almost 25% of respondents feel that their research results are not used by business. Maybe this is the outcome of that,” concluded Kuus.
The third moral: validate your ideas before spending lots of time working on and fine-tuning them. Communicate. Don’t be afraid to ask.
It is said that the hardest part of data science is asking the right questions. Kuus doubts that anyone can ask the right questions without first asking lots of wrong questions. There is that cliche that data scientists talk to data. “I think this is wrong,” said Kuus, “data scientists should talk to people. Because only then is it possible to create insights that have real value.”
To wrap up, Kuus turned to his own experience once again. “Lately I have had the opportunity to talk to data scientists from several organizations,” said Kuus. From these talks he discovered that a lot of the problems that data science teams are facing today have been relevant in software development for decades. “I think that our experience can help data scientists face these problems more easily,” he said.
The three important principles that Kuus hoped to leave his audience with are:
- Regularly discuss why and how you do things in your team
- Choose tools and practices that foster clarity
- Validate your ideas before spending time fine-tuning them
These principles are obvious, said Kuus. However, as it is often happens with obvious things, they are easily forgotten. “I hope that my talk reminded you to think about them in the future,” concluded Kuus.