Ep7: Brittany Bennett on Training the Next Generation of ‘Data for Good’ Practitioners @ Sunrise Movement

After listening to this episode, you’ll be rushing to implement a 'failure of the week' practice on your team.

Brittany Bennett is Data Director at Sunrise Movement, the youth climate movement that numbers tens of thousands of members throughout every US state. 

Given how quickly our industry moves, developing junior data talent is hard, but Brittany’s team at Sunrise makes it look easy. 

And that’s no accident—because Sunrise hires for mission alignment rather than technical background, they dedicate significant resources to training + mentorship.

In this conversation, Tristan, Julia & Brittany dive deep into the opportunity of developing junior data practitioners.

Listen & Subscribe

Listen & subscribe from:

Show Notes

Key points from Brittany...

What is Sunrise Movement and what’s your job entail as Data Director?

So, I'm the data director at Sunrise Movement. Sunrise Movement is a youth climate movement dedicated to passing a Green New Deal and creating millions of good jobs. We consist of over 500 local volunteer hubs in every single state in the country. And that is a network of tens of thousands of members.

What we do is recruit members to our hubs. Next, we train them up in the skills needed to organize locally in their community. Then, we mobilize them sort of nationally in mass action. And finally, if I'm the data director of this movement, my job is to leverage the insights from data analytics to answer the question: are we winning? 

You have a really interesting hiring philosophy, looking for mission alignment first and the hard technical skills can come later. How did you get to that philosophy and how’s that been going for your team?

This is such a great question and one of the primary reasons I enjoy working in my field so much.

So, among data people and progressive politics, we have this informal saying that organizers make the best out of people. And that's because, for us, the most important part of a data job is being able to understand how your work affects the bottom line of organizing. 

Now, domain knowledge is an important part of any data job. When you think about data science skills triangle, it's like hard skills, domain knowledge, and then stats. But, for us, we sort of take it to an extreme and I want to explain why. 

So, if you've ever spent time knocking on doors, making phone calls or running a training program, you understand that tech is not the limiting factor to success for the causes that we care about. There's only so much that optimized data pipelines, machine learning algorithms and world-class data analytics can do to really build power on the left. We are not going to hack our way to a better world. We build power through organizing, and that is by having one conversation and then another conversation, and then another conversation. 

As a data team, we exist to support organizers. So the skill I'm looking for is like: can my data folk work side by side with an organizer, understand what they need, translate what they need into data terms and then deliver it to them?

With bringing dbt onto our tech stack, most of the hard part of our SQL analytics work has been done for them, all of our common joins, all of our common reporting. And so my analysts are then left where the SQL they write can be pretty simple, `select * from where`, and they are left to do what they do best, which is building dashboards, making data accessible and setting measurable goals alongside organizers.

Simply put, coding is not the most difficult part of our job - often we can get by with some pretty low hanging fruit with some basic SQL - it's knowing what to measure in the first place. 

How do you create a safe environment for people that find themselves doing something that they don't know how to do? 

I love this question because I believe at one point or another, whether it was in school, in early childhood, in a relationship, or in work we've all learned to feel shame. And we'd internalized such an intense amount of shame around our abilities, and the way that we move in the workplace. As a manager, I can't control at what point in a person's life they come onto my team, but what I can control is giving them a safe environment. So, I think you're onto something there about the fear of learning something new and this fear of failure. 

A very specific thing I do with one of my reports is to share a failure each. So I share a failure, he shares a failure. Because he came to me the other month and he was like "I am so afraid to tell you about the mistakes that I make in my role because I'm afraid you're going to get mad at me". And that is such a super common feeling. If you're working with a manager where you're like "I am afraid of my managers’ emotional reaction to me saying that I have messed up in some way in my job" - no matter what the severity of that - so we do this thing called the failure of the week and I have opened up about the mistakes that I have made. And I have shown him that even me as a leader, I still make mistakes. 

And I find that for people in a hierarchical organization, it's easier for them to hide their mistakes. For lower-ranking people, their metrics are usually very clearly being seen by their manager. 

How do you think about the performance management of some folks who are learning the trade? It's actually very uncertain what good looks like. 

I stick to pretty rigorous project management techniques where at the start of every project we have a project scope sheet where we outline fully what success looks like for a project.

For example, if someone's working on a training program, it's like you need to have their pre-imposed surveys drafted, need to be able to analyze them, your final report needs to look like this. And then within that, my analyst and engineers are free to make decisions on their own - they are fully the owner of their projects. And then when it comes time for me to give them feedback around their work, we first go back to the scoping doc and make sure like "okay did you actually meet the deliverables that we agreed upon together?" If that's met, good, the job got done. 

And then there's always this extra bit of professional development that I do where I'm like, "okay, your code may have worked, your code may have gotten the job done.” We're actually going to take some time during this meeting to look at it, and I'm going to give you feedback to make it more robust, how to make it better, do it in our style, whatever. 

So there's kind of two bars. Number one is: did the organizer do the thing? Did you help the organizer with what they wanted you to help with? 

Boom, we can often always do that. And then it's like I always have to hold them to the bar of: Are you being a good analytics engineer? And that's just me trying to develop my team and give them feedback of how, even if they're meeting the bar for doing the work, they could be meeting the bar to become a great analytics engineer.

How do you think about career progression and mentorship? Any tips or advice that you've found to be successful for yourself?

I think that idea is really interesting because data science has a myriad of boot camps and Medium articles and so much infrastructure out there, right? And I feel like analytics and analytics engineering aren't on par with that.

So, I know that when I set off to learn data engineering, I was immediately dismayed by the lack of resources or even just in the set of agreed-upon "hey, these are the skills you need to know to be a good data engineer." I could not find that list anywhere, I really wanted it. 

Everyone in my team has a mentor. I have Claire Carroll, who I'm absolutely so excited to be working with. And then the rest of my team has Jason Wiener. Everyone in my team has built-in mentorship as part of their job. They're supposed to meet with their mentor, they're supposed to do additional homework, and that happens during work hours.

So for us, I really believe in the power of mentorship and I believe in mentorship because there aren't as many data engineering, analytics engineering boot camps. It was why I was so excited that you all released your foundry program, because I'm like "oh, that solves some of the problems here". Like, how does knowledge get passed down from more senior analytics engineers to more junior analytics engineers when even the field of analytics engineering is only a few years old or nascent, right?

There's this sudden need for analytics engineering, but like the rest of the educational resource infrastructure hasn't yet caught up to the booming need. And I'm just really excited to see more work that dbt Labs is doing in order to create the infrastructure to actually train up this talent.

How do you do career ladders, compensation scale, etc.? 

It's funny that you ask that because I work at an organization that takes a different approach to salary. We have a flat salary structure at Sunrise where everyone makes between $50k and $80k, and it's a needs-based salary. So you choose your own salary, it's a very interesting model.

We're in the process of potentially reconsidering that in bargaining with our union. But at the moment let’s just say that, for example, every single person at Sunrise makes the same amount of money and it's pretty equal. So, for us, if I were to promote someone, they would not be making any more money than they were making previously. 

When I think about it, I think about how am I constantly providing new challenges to my team? How am I meeting the career development goals of my team?

For example, if I'm working with someone who's like "I really like digital analytics, I want to stay doing this and I want to learn more about it". My response as the manager is "cool, I'm going to connect you with mentors, consultants, experts in the field so that you can learn from them how to do this job better.” 

We also have a system on my team where everyone has their speciality. I have an analyst that works just with our organizers, I have an analyst that works with our hubs, I have an analyst that works with our digital teams. Even then, we use an intake system for all new projects. So, as new projects come across our plate, anyone on my team can take a new project if they want to push their skills. 

For example, if I have someone and they're like "I want to learn data engineering, I want to learn how to write better Python,” they are more than welcome to grab that intake form that's like a data engineering script, and then I would help them through and help them learn the skills to do it. 

So, I have crafted a team where, hopefully, people do their job, people like fulfilling their core role, people have the ability to explore other kinds of data-world work within the realm of our organization. They have a mentor that's pushing them technically, and I encourage my team to write about their work and to share about their work and give talks. So, overall, I think that is a healthy work environment for feeling like you are fulfilled in your work.

More from Brittany

Check out Brittany’s blog here, and follow Brittany on twitter @thebmbennett.