This blog post is Unfiltered
I’ve been at GitLab five months now - with every merge request committed and milestone met, GitLab team members collaborate on innovative and efficient methods of delivering some of the world's best software. Besides this, I’ve also noticed that GitLab team members do a superb job of creating an environment that allows each of our peers to contribute, be heard, and bring their whole selves to work. Once you’ve gotten a taste of being part of that kind of community you get to see how much it matters in writing good code - talented and inclusive teams are more creative, efficient, and happier in the workplace.
The Gitlab Handbook offers amazing explanations about our values and resources for living them to your best ability. One of our values ‘Diversity, Inclusion, and Belonging’ has the following note on this value that I really appreciate:
“… Diversity is having a seat at the table, Inclusion is having a voice and feeling empowered to use it, and Belonging is acknowledgement of your voice being heard along with creating an environment where team members feel secure to be themselves…”
Anyone can, and everyone should strive to nurture these values. For myself, as a person with intersecting levels of privilege who is not a member of an underrepresented group, allyship is a fantastic way to help build a better working environment. Though, being honest, if you asked me 6 months ago what allyship meant, I couldn't have told you. Going over the Handbook was a great start and I highly encourage it, as was working through my own diversity training but I also wanted to put together a small piece for anyone else getting started on their journey in allyship. Something my old bodybuilding coach Blue Shinners used to tell me came to mind when I started the learning process;
It's not complicated, but that doesn't make it easy - Blue Shinners
For context on this piece, I want to let you know the following: I am a white, cisgender male (pronouns: he|him|his). I also have a lot of privilege along other lines of intersectionality (e.g. heterosexual, neurotypical, a citizen of an affluent, peaceful nation, etc).
I am far from an expert in the field of allyship or building inclusive work environments, so I’m relying on my lived experiences and what I’ve learned from reading and listening to others. Regarding scope, I am committed to using my position within GitLab to help foster an inclusive and diverse environment aligned with GitLab’s core values.
I’ve got to say - for me, becoming a better ally looks a lot more like a patchwork of small bursts of reading, learning little bits in social interactions, being corrected here and there, apologizing, and using what I’ve learned to do better. It isn’t always tidy, but if I were to lay my journey out in general steps, it would look a little something like this: Getting excited about learning and listening, making space, and making spaces inclusive. Contributing to a better culture, where and how you can. If you see something, (and it’s safe for you to do so,) say something. Though most of all accept that you will make mistakes, and strive for course correction.
I personally make a lot of mistakes. The uncomfortable truth about making mistakes is they are part of lifeand more part of living honestly. Alan Watts very famously said that you do not know where your choices come from when you live honestly, and this can cause you to fumble as you explore like a toddler taking their first steps. One of the most difficult things I have ever done is to honestly level the question at myself;
If you make mistakes in all other areas of life, is it possible you also make mistakes in this area?
The natural instinct is to pull back in
anger(fear), claiming you are a good person and would never intentionally set out to treat people differently based on something as shallow as how they look or present themseleves. Regardless of how you feel, making mistakes is inevitable purely due to the fact that without a well thought out dose of empathy, you simply cannot assume someone else's situation nor experience.
Getting excited about learning and listening
Search for answers - you don’t have to know everything about the historical and cultural basis of social injustice, but I know that even a few articles or YouTube videos here and there have made the difference in giving me a better foundation for understanding, open-mindedness, kindness, and better conduct.
Listen to your peers, partners, and colleagues when they share their experiences or important pieces of news with you - and be willing to share yours, if asked.
Know your ‘-isms’ and learn about unconscious biases - especially your own. If you haven’t experienced certain kinds of prejudice or discrimination it may be while until you learn about them or how you unconsciously maintain them. Knowing about them lets you make an active choice in reducing toxic behaviors in shared spaces.
If you can’t find what you’re looking for in your research, don’t be afraid to ask for help. When possible, ask the appropriate person for help, like your team supervisor, or even ask in the GitLab diversity slack channel (I personally learn a lot from this channel each day).
When the context is more specific, ask your peers - but leave room for individuals to say no or for groups to leave anonymous feedback.
Knowledge is necessary to good allyship. And it’s sufficient when paired with inclusive, affirming actions. Like with any good piece of code, go for the minimum viable product - learn more, incorporate it into your daily actions, be willing to keep adding to that knowledge base and growing.
Making space, and making spaces inclusive
Learn about the space you’re in and space you occupy - for myself, this journey meant coming through the understanding that software companies are overwhelmingly composed of people that look just like me. Learning more about how and why some groups are underrepresented, even in companies like GitLab, is another important step in allyship.
Looking at GitLab’s values, we’re encouraged to see others succeed and help where we can. Good allyship is about doing my best to ensure that underrepresented voices are given at least as much space as my own, both by letting people know you want their contribution with affirming and inclusive language and by showing your appreciation for those contributions by giving credit and offering praise centered on their hard work.
Use common sense and be kind in your interactions with your colleagues. Don’t make assumptions. Be flexible and open-minded. Be respectful of others’ privacy and get excited about what they’re willing to share with you, from their quirks to their life story and family album. These interactions create the bond GitLab team memebers share and makes this all-remote team that you love to work with.
Contribute to a better culture, where and how you can
Improving the work we do at GitLab is often about your contributions, but it’s also about how good a job we do as allies to ensure that all of our ideas and contributions receive time, consideration, and credit. As a good ally, this means remembering to uplift and make space for the most marginal voices.
Celebrate intersectional as well as cross-functional collaboration by considering paired-programming or mentorship with someone new. The benefit of working at GitLab is that it is teeming with talented developers from all backgrounds. When you issue or consider a request for paired programming or mentorship, center the goals and timeline to confirm you both have the time and skills to get it all in. Be willing to meet the other person where they’re at: be flexible, respectful, and accommodating of their needs in the workplace, ask them about their experiences, be willing to share yours.
Share your time and your love of code with your local community - hundreds of cities worldwide have organizations and education programs that promote programming for marginalized groups and youth. Even if it’s during traditional working hours, at GitLab, we have the flexibility of working things out with our supervisor to support the events and people that won’t wait until ‘after work’. A great example of this is the Vue Vixens which are one of my personal favorites.
Donate to an organization or cause that is able to do the work you can’t on your own. Did you know that GitLab has a pretty great donation matching program proposal in the makes? It’s nice to know they’ll back you up on the causes you support.
If you see something (and it’s safe for you to do so), say something. Call out discrimination - address the behavior, without labeling the person. This comes back to empathy in the workplace. Be in the shoes of the person or group experiencing the discriminatory behaviour, and be in the shoes of the person behind the behaviour. Support the marginalized person or group, to reinforce the equal value of everyone of GitLab. Addressing someone’s discriminatory behaviour and holding them accountable gives them an opportunity to adopt, adapt, and improve.
We have a lot of options in how we respond to discriminatory behavior. I go into all interactions with my team assuming good intent, and keep in mind that we are each more than our work or individual actions. I also keep in mind that while discriminatory behavior can be addressed directly and in the moment or context, it can also be addressed indirectly, or in a 1-on-1 afterwards, which can offer a more approachable context for difficult feedback.
I recognize that in an ideal world, everyone would feel comfortable calling out discriminatory behavior, but it isn’t always safe for everyone to do so - especially members of the groups being discriminated against. That’s where ally’s like myself come in - inclusive spaces are about shared work, and I have more opportunities than many to help build that.
Accept that you will make mistakes, and strive for course correction in all areas.
“Many would-be allies fear making mistakes that could have them labeled as “-ist” or “-ic” (racist, sexist, transphobic, homophobic, etc). But as an ally, you’re also affected by a system of oppression. This means that as an ally, there is much to unlearn and learn—mistakes are expected. You need to own this as fact and should be willing to embrace the daily work of doing better.”
I’ve mentioned before that this is a core takeaway for developers and team leaders alike. Whether we’re creating a merge request, bringing our true selves to work, or becoming a better ally, we should do so with a low sense of shame and no ego.
You will make mistakes. I promise. We all will. But when it comes to allyship, it won’t just be a blow to the ego. It will be to the part of ourselves that loves GitLab for the people we get to work with every day and hates the idea of hurting anyone here.
So here are some notes for getting through those sticky occasions, and iterating better when someone calls out that you haven’t been the best ally:
In simple terms: say thank you, say sorry, iterate and do better.
- center around yourself
- prioritize your intention above the impact of your actions
- deny the other person’s lived experience, derail or deflect from the issue in your apology
- avoid arguing semantics on how the issue was brought to your attention
- ask that person to accept inequality or microaggressions as a fact of life
- blame them or their actions for what happened
- retaliate against the person either actively or passively
- ask if they’re okay and center their experience
- listen to what they have to say, acknowledge what happened and your role in it
- apologize as gracefully as possible
- understand and learn from what happened, do your homework
- stop the behavior and modify the pattern that led to it.
Keep in mind that it’s okay to ask for the person’s feedback on what you can do to be a better ally or for a clarification on what happened was problematic, but remember to center their experience and leave the other person space to refuse (fixing the behaviour is contribution you make to a more inclusive space going forward). Where I come from, it’s mandatory to add that your owe the person a pint of Guiness down at the pub after a workplace chat… maybe a coffee chat is a better call for an all-remote company though.
Remember that we are more than our work or our individual behaviors. But over time, we do become associated with a track record comprising both of those things. When our colleagues do code review or call us out, it’s an opportunity for us to grow and build better habits. And as long as we continue to iterate better, our contributions to GitLab will be more meaningful and people will see us in the light of the changes we’ve made (not the small slips along the way).
Being an ally is an ongoing journey where we have many opportunities to contribute, collaborate, learn, get feedback, and iterate better… so pretty much the same as everything else we do at GitLab. And with this one, we grow better interactions with some of the most talented developers we’ll ever get to work with.
As with every other post, this is also a collaboration… so whether it’s further resources, suggested additions, punctuation edits, or even a few callouts that I should look out for, it’s all very welcome. It's how we all grow, it’s how I hope I am becoming a better ally.