The 'I' in Team: Peer-to-Peer Best Practices for Growing Data Science Teams - posit::conf(2023)
Presented by Liz Roten R users don't always come in sets. Often, you may be the only user on in the cubicle-block. But, one miraculous day, your manager finally fills the void and you welcome more folks on your team. Suddenly, the little R system you created to suit your needs, like a custom package, code styling, and file organization, isn't just for you. Want to suddenly overhaul that one package you wrote two years ago? It probably won't work when your colleagues try to update it. Your new teammates are data.table fans, but you prefer the tidyverse. Do you need to refactor? Are style choices, like indentation important when collaborating, or are you just being persnickety? In this talk, you will learn how to bring new teammates on board and blend your respective styles without pulling your hair out. Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Building effective data science teams. Session Code: TALK-1063
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Good afternoon, everyone. Thank you so much for coming. My name is Liz Roatan. I'm a data scientist, and I am here to make the argument that there is an I in Team, and some peer-to-peer best practices for growing data science teams.
So in the beginning, I started at my organization, the Metropolitan Council, in St. Paul, Minnesota. We're a regional governing body. And when I started, we had a very tiny data science team. And by tiny, I mean a total of two people. We did not really work with each other. Our projects were totally separate.
But we had the great experience, at least my manager did, of proving to the rest of the organization that data science was valuable, and the great work that we did proved it. We had some turnover over time, but we also were able to expand and evangelize a bit about R, version control, GitHub, et cetera, and more people started using data science tools. But it was really clear that we were all used to working in our own little bubbles. And this became very clear with something I'll call the incident.
The incident
So how bad was this incident? Back in the beginning, I wrote an R package for the council, but actually it wasn't really for the council. My manager was the only one using it, so it was just for me. And I got to do whatever I wanted with it. It was great. It's called Counselor, made a logo.
It has things like corporate colors, database connections, templates, classic internal R package. And as we got more people on board using R, using GitHub, I got more people to install the package and start actually using it for themselves, which was a really amazing feeling.
At some point I decided that we should just completely rehaul the way that fonts were sized in our ggplot2 theme, which is fine. But it had some unintended side effects. So I wrote this update, pushed it out, had all my colleagues install it. And it installed, which I considered a win.
However, my colleague installed the update while they were working on a very time-sensitive report. And for any of you that have worked with going from R Markdown to Microsoft Word, there is a lot of potential frustration there with plots.
So the thing is that what I did didn't break their code. It just changed things. So if we see this plot, where we have my plot plus theme counsel, where the font sizes are correct, the title is one of the largest fonts that you see, you can read the X and Y axis as well as the legend title, the axis titles, all of it makes sense. And the caption is tiny, like it should be.
But then without breaking the code, so there was no, like, warning or, like, clear this didn't work, the plot did this, where the caption is massive, the text on the X and Y axis is practically nonexistent. The legend title is tiny. The title title font is different. And the Y axis title is rotated. And this isn't none of these are bad. But when you're trying to get something going, it's not fun when something changes right underneath you.
So what went wrong? There were several things. First, there was inaccurate and inadequate documentation on my part. There was also a lack of communication. So I didn't adequately convey the changes I was making to my colleague, and so they didn't know what to expect. And we also had mismatched priorities. I was having fun tinkering with my package, and my colleague actually had something to get out into the world.
And the next question is could my manager have prevented this? And the answer is no. My manager could not have prevented this. This is an interpersonal team thing. And that's where my argument comes in.
There is an I in team
There is an I in team. Because teams are groups of individuals working together. Note I in individuals. And you, as an individual team member, can shape your team by caring for your new team members and your current team members, seeing how you fit into your team— sorry.
Seeing how you fit into your team and changing how you work. And as the turnover has happened at my job and we brought more people on board, there are a few things I've learned that I'd like to share with you today. And one is that when you have a new colleague coming on board, it's your responsibility to bring them on board, too. It's not just HR. It's not just your manager. It's you as well.
And one is that when you have a new colleague coming on board, it's your responsibility to bring them on board, too. It's not just HR. It's not just your manager. It's you as well.
So when you're bringing on a new teammate, three things. Make the implicit explicit. All knowledge is valid and valuable. And document. Also known as make life easier for your friends.
Make the implicit explicit
So first, make the implicit explicit. The story here is from a commencement speech by a fairly famous American writer in which there are a couple fish swimming around. In this instance, we'll say that these are you and your coworker having a great time being fish. A new fish comes along. And then they ask a fairly innocuous question. How's the water? To which there's silence. And then what the hell is water?
And now you need to understand that this fish is having a crisis. They don't know what they've been living in their entire life. What does it mean to be surrounded by this thing constantly all the time? And why am I just now being told that there's water? So this fish is having a struggle. And you don't need to be an anxious fish. Don't deny that water exists. And by water, I mean your workplace culture.
Everyone has pet peeves and preferences. Every workplace and every team within a workplace has a culture. And that's not inherently bad. But you need to recognize it for what it is. And because otherwise, when a new person comes in, you're giving them the task of proving that like, oh, no, there is a culture here, in addition to figuring out if they want to stay on the team. Don't give your new coworker the task of defining what water is in addition to evaluating if the water is right for them.
There are a few ways you can define your water, and these are just a couple starting questions. What does your weekly schedule look like? How much time do you spend in big meetings, one-on-one meetings, really deep focused time? What does it look like for you? What tools do you use every day? Why? And I mean every single piece of anything that you touch throughout the entire day. Make a list. And how do you use it?
And what expectations does your workgroup have around email or message response times? Same thing goes with having a status indicator in your Microsoft Teams or Slack, as well as any after-hours communication expectations.
All knowledge is valid and valuable
The second, all knowledge is valid and valuable. No one is an empty vessel. And so all of the knowledge that this new person is bringing to your team is valuable. No matter where they're coming from, if they're coming from a different industry, coming straight from college, coming straight from an online course, wherever they're coming from, the knowledge that they have is useful. And even if it seems very unrelated. For whatever reason in my workplace, we've attracted a lot of PhD ecologists, which is not what we do. And I've learned so much from them.
You also have to remember that your knowledge is not inherently superior just because you've been at this workplace longer. So when you're bringing this new colleague in, it's important to give them some grace. Patients will prove best. Whether you're introducing them to a new tool, integrating them into the broader organization and getting all those social relationships sorted out. Whatever it is, have patience, and it will pay off.
And remember that you're also on probation. In my workplace, you are hired, you have a six-month period, and at the end of that, the employer can decide whether to keep you. And they're on probation, but you as a team member are also on probation. They're figuring out if they want to work with you. And that's important, too.
Also don't rely on catch-all assumptions. Ask for specifics. For example, two people who have Git and GitHub on their resume but have very different ways of working with Git will have different experiences. Someone who's on the command line is going to have a very different experience than someone like me who relies on a really nice user interface to visualize branches. Neither of these are necessarily better than the other one, but you need to ask for those specifics rather than assuming.
Document — make life easier for your friends
And finally, document, aka make life easier for your friends. So an experience you may have had at breakfast this morning, not in this hotel, but whenever you had breakfast, is if you were to have cereal, which comes first? The cereal or the milk? And there are all sorts of answers. There's also questions like why cereal? What kind of cereal? Should it be sugary, organic, whole grain? What kind of cereal? And then what kind of milk? Should it be milk, cow milk? What kind of cow milk? What kind of not cow milk? There are all sorts of ways.
And I'm going to be truthfully brutal with you guys. It doesn't matter. What does matter is that you remember the bowl in which to put your cereal and milk. Documentation is the bowl.
Documentation is the bowl.
Data science is an incredibly creative field, which is one reason why I enjoy working in data science. There are many ways to solve a problem. And by trying to force everyone into one single way, you're not taking advantage of all of the gifts and knowledge that they have to bring. Embrace the diversity of opinion and experience, even if it's hard for you as the existing person, and it will be hard for the new person coming in. Just remember whenever you're going through something to leave a trail for others to follow. Add in comments in your code, every few lines. Leave a trail of breadcrumbs towards the final outcome or whatever process.
Documentation is also a matter of investment. You're investing in tools that encourage documentation and lower the cognitive load. You're also investing in the time that it takes to document, clean up, organize, etc. Your work. And you're investing in strong social relationships. This might not seem very intuitive, but follow me. Documentation is communication in written form. And for good communication, you need to know your audience. Kind of like if you're giving a talk at a conference.
So this means that work doesn't always feel like work. Schedule time to build connections and trust. In person, virtual, hybrid, all of the above. Social gatherings, virtual or in person, are just as valuable as that coveted, like, afternoon hours of focus. Really. And it took me a while to kind of accept that.
And try making every other team meeting a casual hangout. That's something that we've done in my work group. We have a weekly team meeting, and one week we talk about work. The next week we talk about not work. And I've gotten to know my colleagues so much more and have gained a better perspective of who they are as people and the backgrounds that they have. My colleagues are really great. They're really interesting people. And I enjoy working with them.
Ultimately, at the end of the day, there is an I in team. Several I's. Teams are made up of individuals. And it's not only the manager's job to make the team work. It's your responsibility as a team member as well. Onboarding is a unique and critical time when someone is coming in. And you can take advantage of that time to gain a really great relationship with them and set them up for success in your workplace.
I've grown immensely from working with my colleagues. And that isn't really because I have a great manager. My manager is pretty great. But it's because of the time that we've invested in each other as a team. And not because my manager waves a magic wand and makes everything work. Thank you.
Q&A
Thank you so much, Liz. We'll have time for some questions. So how would you... All these recommendations that you've made, how would you pitch those to management? Because even though it's I, it needs some broader support, right?
This particularly... I think particularly in, like, scheduling hangout time, if you can start by pitching it small. So we're gonna do a 15-minute coffee break, particularly when COVID started and we all started working virtually, just having a pop-up 15, 30-minute coffee break is permissible. Like, that seems okay. And you kind of work your way up. Because you find value and you build... You prove the point as to why that little 15 minutes is worthwhile. And then maybe the next time you ask, it's like, how about a lunch? Or a secret lunch and learn that is learning about your new colleagues and not about databases or something. And you can work your way up.
