Original Source Here
Five Ways to Cultivate a Healthy Culture on a Data Science Team
Strategic approaches to help you foster a strong culture in your data science team
Hello all! We’re back with a new post today setting aside learning a new hard skill to focus on some important soft skills in the data science realm. It goes without saying that a healthy working culture is important for any job, and the same holds true for data scientists and machine learning engineers. A healthy working culture can help drive productivity, retain quality employees, and simply keep your teammates happy.
While I am now a practicing machine learning engineer in my day job, what you may not know is that most of my educational and work roots are in business and leadership. A very short background about me: I made a 180 degree pivot away from business-oriented roles to the data science world a few years ago. Thus, I actually don’t have a formal degree in any sort of data nor computer science field. I actually have an M.A. in Organizational Leadership and hold several leadership-oriented certifications like the Project Management Professional (PMP), Certified Scrum Master (CSM), and some more.
Okay, enough tooting my own horn! The only reason I share that is because as I stepped into my current machine learning engineer role, I brought many of these same principles here, and almost two years later, I’m really proud of the group of people I work with. They’re a fun group of folks to work with, and everybody does a great job at teaching and encouraging one another. The productive throughput of my team is equally high, too!
Of course, I want to see everybody thrive and succeed, so I thought I’d share five strategies to help cultivate your own data science team’s culture. Just being candid, the underlying principles for all these strategies are equally important for any non-data science job, but where possible, I put a little more of a tactical spin on these strategies specifically for data science roles.
Without further ado, let’s jump into our strategies!
1. Accept all ideas with grace.
This is number one on the list for good reason. Even though a lot of things like statistical rigor are key staples of the role, a data scientist often has to be creative with the way they do many things. Keeping in mind that a data scientist’s predictive model has a direct tie to solving a business problem, remember that even without data science, there is often more than one way to solve a business problem. Thus, there will be different options for coordinating different models for different purposes, different approaches for modeling in general (e.g. standard supervised learning vs. deep learning), and more.
Of course, some ideas are better than others, but it’s important to respect all ideas with the same level of grace. Nothing shuts down a person faster when you tell them their idea is stupid. It’s extremely demeaning, and a person is far less inclined to share new ideas in the future. This person may have had awesome ideas for future projects, but they may not share them in fear of being ridiculed again.
That’s a loss on multiple levels. It’s obviously a loss to the business since they miss out on potentially great ideas, but it’s also a loss for the team in general. If the team becomes rigid about sharing new ideas, happiness levels will surely drop, and there’s a strong chance of individuals leaving the company entirely.
If you want to cultivate an open spirit of grace on your team, start by extending that grace yourself. Even if you disagree with an idea, thank the person for their thoughts and open a dialogue toward steering the group toward a better idea. Who knows, maybe part of the original “bad idea” can still influence the better direction? But the grace has to start somewhere, and there’s no better place to start than with you.
2. Consider holding a regular meeting of showcasing new skills.
In the strategy above, I mentioned that nothing shuts a person down faster than demeaning them. I’d say the next thing that shuts a person down quickly is lack of knowledge about a given topic. Let’s be honest: nobody likes to look dumb. We tend to overcompensate for our lack of knowledge by either doubling down on what we’re comfortable with or shrinking back into a corner. One of the biggest problems I’ve noticed with the data analytics world in general is that many data scientists will double down on traditional statistical modeling because newer tactics like deep learning can be a challenge to learn.
One very tactical way around this is by holding regular meetings to share new skills learned for the rest of the team. My team today does this for one hour every other week, and it’s honestly one of my favorite regular meetings. Not only is it great to learn a new skill, but there often is great dialogue around how to apply that new skill in different ways for different projects.
To that last point regarding dialogue, I think this works much better if the group is much smaller. I know it’s tempting to invite everybody in your department to learn something new, but once you start getting over ten people, having a reasonable dialogue sort of goes out the door. It just gets too unwieldy with too many people. There might be room for a different kind of skills meeting for a larger audience, but for best results, I would encourage starting with a smaller group of people.
3. Ensure clarity on team best practices.
In the last strategy, we mentioned that people are turned off when they lack knowledge on something, and while general data science skills are one thing, team best practices and tactics are another. Organization and standards can help a team to thrive, but they’re not useful if it’s not clear to everybody how those practices manifest. Data science is no exception to this. I’m certain your team probably has a way of organizing Git repositories, obtaining data from a central source, and more.
There are two specific things I’ll recommend here: one obvious and the other not as obvious. First the obvious one: document all your team’s best practices somewhere. Even if it’s all in a big README in one Git project or a Word document saved in a place where everybody knows to access it, that’s still better than not having written down anything at all.
The second and more important piece is to ensure that your team’s practices are not complex and simple enough to remember at a conceptual level. Even if you write it all down, if the processes are too complex or cumbersome, nobody is going to want to follow them. Period. The documentation should be looked at as a reference guide to specifically do something you already have a general conceptualization of already.
For example, you’re probably well aware that your data is stored in a central source. The documentation should serve as a reference for all the nitty gritty details that nobody should reasonably have to memorize on accessing that central data source. Remember, even if something complex can be really cool if done right, it’s useless if nobody has the inclination to do it on a consistent basis.
4. Promote the concept of pair programming.
Modern data science obviously goes hand-in-hand with modern computer science in the fact that we use technologies like Python or R to build predictive models. Just a regular software developers often have to struggle to get something working in code, a data scientist likewise faces many of the same challenges when enabling a data science effort in code. As a machine learning engineer, I can guarantee you I’ve spent way more time debugging code that I think should be working than writing the code in the first place!
If you’re not aware, pair programming is the strategy of having two or more people work on the same code at a single time. Usually one person will take over the typing and share their screen virtually with their teammate(s), and they will have a back-and-forth dialogue on how to code something. This can often lead toward new ideas for better ways to code things, and I personally use pair programming as an excellent time to debug something not working. Because computer science requires such a precise syntax, a simple typo can wreak havoc on the functionality of your code. A second set of eyes can often sniff out those syntax errors very quickly!
5. Seek little opportunities to have fun!
The temptation of the business world is to state that anything not directly related to promoting the business is a waste of time. While I can certainly agree that a team spending a solid majority of their time goofing off is bad for a company’s bottom line, I think it’s important to remember that happy workers = productive workers. Especially in this time of the “great migration” with many data scientists taking jobs elsewhere, the happiness factor is extremely important for retaining those quality folks.
In addition to being a machine learning engineer, I also serve as my team’s scrum master. I know some scrum masters might steer conversation back to the business matter at hand if it starts to drift off into a personal, fun topic, but I’ll personally allow it every once in a while. Yeah, the company doesn’t care what my teammates think about video games we played or movies we watched, but if I can keep my team’s morale high, I can guarantee the company’s bottom line would be substantially improved through higher productivity and retention of quality employees.
Trending AI/ML Article Identified & Digested via Granola by Ramsey Elbasheer; a Machine-Driven RSS Bot