I wanted to wake up every day excited to go to work.

It was June of 2017 and with three years of software work under my belt I wanted to work somewhere that made me feel included, excited and appreciated. When I met with musx and the opportunity to grow an engineering organization presented itself, I couldn’t say no — and the ensuing months have been among the most intense, hectic and beloved of my professional life. More than anything I love what I do because of the people with whom I’m doing it, and the way we’ve decided to work together.

As the inaugural engineer at musx I had a unique opportunity to think about what kind of team we wanted to build before we started building it. My experiences as a Latina engineer had informed how teams could be exclusive or make people feel uncomfortable — even without meaning to. What was exciting, and surprisingly difficult, to figure out was what a dream engineering team would be like: how it would function, and what to do to get there?

It’s easy to find women and people of color to staff an engineering team — if you’re looking. It’s like my grandfather would say, “Sí se puede, si se quiere” — you can do it if you want/desire to. I’d like to share some tangible ways that anyone can build a more inclusive technical team, while building a stronger team that has a better understanding of the code base, can communicate across departments in the company, and bands together to support each other when the going gets rough.

Like most things, it’s a work in progress. That said, in hindsight there were things we did before building a team turned out to be essential to creating the conditions for our success. There are things we do in the day-to-day experience that are important and surely every time we decide to bring someone into the organization we’ve made decisions geared towards keeping our engineering team inclusive. This is meant as a way to share our experiences so as to empower others to create inclusive engineering organizations that, hopefully make you excited to go to work in the morning.

Write It Down

Write out the way you would like your organization to function. This includes a general motto, and example is: “Be kind for everyone is fighting a hard battle with code”, as well as the policies and the procedures that you will implement to support this culture. A few examples that we used include: a PR template, code review guidelines, project management template, and an explanation of Storytime — our own version of in depth code review.

Writing things down gives you the ability to have a concrete vision, and allows everyone to be able to refer to that vision when needed. Additionally, you can open source this document within your organization, and everyone can buy in that way.

Keep Learning

Making a commitment to an inclusive engineering team means that you are willing to look outside of “traditional“ channels, which means people who may or may not have a formal computer science degree, from less traditionally “elite“ colleges, or even who are self-taught or learned from a bootcamp/code school. You should adjust your job descriptions accordingly. That also means that you need to make sure you create an environment of continuous learning.

Creating a learning environment can mean a lot of different things. Making sure you budget for conferences and courses, for example, encouraging people code review and pair program together, is probably the first place you want to start. The benefits here include a larger familiarity for everyone with the code base, as well as each other, and as a bonus you create a more trusting environment where people can pull together, and depend on each other, to solve the more difficult technical problems you’ll encounter.

Just as inviting people to collaborate on open source guidelines allows people to buy in, creating opportunities for collaboration and interdependence creates a culture where people are bought in to their team, and by extension the product they are building.

Change Small, Important Things

There are small, important things you can change that will make big, important changes in your organization. Do your job descriptions use the words “ninja” or “rockstar”? Do you require a CS degree? Do you ask for 5 years experience for an entry level role? A Masters for a senior role?

I invite you to reconsider if that’s the case. Do you want a ninja or a team player? Do you need a CS degree or familiarity with new frameworks? Do you need experience or hunger? Do you need a Masters or someone who knows your code base? All of these things are small and hard to change, but will result in vastly different effects on your company’s hiring.

The same goes for interviewing.

Do you ask the same interview questions you always ask but also expect different results? Why do you whiteboard in interviews — does that reflect the day-to-day? If not, why are you doing it? Are you asking questions that help you determine whether this person will be a good team member who works well with others? If no, then why do you expect your interview process to give you those candidates?

Review The Feedback Loop

If you’re bringing different people into your organization that means you need to be different, too — especially in the way you give feedback. I found it difficult myself to examine ways to give feedback that were not inherently masculinized: killing it, slam dunk, pinch hitter, and the like. When I asked, I found that people really want feedback that will help them grow — and that’s the hardest kind to give.

Feedback can mean everything from high-fives to asking for more in a code review (one of the ways we give feedback at musx is the DJ airhorn every time something awesome happens). Determine what your team needs/wants and find a middle ground to giving it to them. For example I’ve found that highlighting positively good work while also noting room for improvement — I suggest you write documentation / update tests / break this out into a service — is actually helpful to folks & results in real growth for them, and better code for you.

At the end of the day what all of this means is that you and your team will enjoy your work, and working together, more. And because you collaborate, there will be room for everyone to learn, so you don’t have to stick to a diet of white guys with CS degrees, and you may even learn new ways of doing engineer work, and you may get to a point where you smile for no reason because you didn’t know you could love going to work in a Monday so much.

I did.

If you have questions feel free to ping me on Twitter: @sarachicad .