It was in the PyLadies of Berlin community that I met Eli Flores, a mentor and friend who ultimately referred me for the interview. I would probably not have had a chance for an interview in Sauce Labs if it hadn’t been for Eli.
My CV was bad.
I was trying to assert technical skills I didn’t have, and trying to emulate what I thought an interviewer for the position would want to read. Of course, the interview selection process is difficult, too. Somebody has to sift through stacks of paper to find someone with the right skills, somebody who fits into the required role, while simultaneously hoping for someone to bring a unique perspective to the organization. On the one hand, you offer a chance to interview, trusting the judgment of someone you trust. On the other hand, you may end up having clones of the people around you.
This is where referral programs shine the most. And this was the story of how I got my first job in tech.
Was a referral enough? Many would consider that they’d done their good deed for the year. But not Eli.
Eli was the first female software engineer to be hired by Sauce Labs in Germany. By the time I arrived, there were three of us: Eli, myself, and Elizabeth, a junior hired one year before. Based on her own struggles, Eli kept an eye on me, invited me for constant check-ins and provided me with practical information about creating my career path based on what the company would consider a check list. She didn’t just share a link and walk away. She explained to me what it meant, and some “traps” that were built in to the system. Leadership, at the time, hadn’t been trained to recognize their biases, and that had affected Eli’s career path.
Besides that, she was the one putting together a formal document explaining to the ones with the power to make decisions why they needed to give me a junior position at the end of my internship. She gathered information among my peers, found out who had hiring power, prepared them months before my contract ended, and gave me the insight I needed to defend my position.
I did my part.
When things looked uncertain about my contract renewal, I asked a friend and mentor what to do, and what was expected. I asked others who’d been in my place recently. I built a document measuring my progress along the months, ensuring that my achievements clearly intersected with the company’s interpretation of the engineering career path. With that, I could demonstrate that Eli was right: They had every reason to keep me, not according to subjective feelings, but with objective metrics.
Defining my role
There was still a big problem, though. Sauce wanted to keep me, but they didn’t know what to do with me. Junior roles require guidance, and the progressive collection of knowledge. I’d found a passion for the Open Source Program Office, where I could actively collaborate with the open source community. But an OSPO may be one of the most complex departments in a company. It gathers open source and business understanding, and it requires autonomy to make connections between business needs and the needs of open source. My peers were mostly staff engineers, contributing to open source projects critical to the business, and those are complex contributions.
One of my peers, Christian Bromann, was also seeking to grow his managerial skills, and so he took me under his wing. We started having regular 1-on-1 sessions, as we discussed what it meant to be doing open source in a business setting. He invited me to get closer to the foundations and projects he was part of, and we did several paired programming sessions to help me understand what mattered most to engineers tasked with meeting specific requirements. He unapologetically placed a chair at the company’s table for me, integrating me into the business, and so my role became clear and defined.
I had help from several colleagues from various other departments to stay and grow as a professional. They each showed me all the other things I didn’t know about the corporate world, including the single most important thing that I didn’t know existed in business: the way we were actually working to make lives better. We had diversity, equity, and inclusion (DEI) groups, environmental, employee resource groups, informal mentorship, and cross department support. The best thing about Sauce Labs is our people. They are incredibly smart and passionate humans, from whom I learn lessons daily.
A short time later, I decided it was time for me to give back.
I looked back and saw all the others that came before me, and helped me land a job I enjoy and that had critically improved my life. I urgently felt the need to bring another chair to this table for someone else. I started digging to find a way to make sense of how a for-profit organization could have a fellowship program.
A fellowship program in a for-profit organization
I was now formally occupying a role that bridged the OSPO and the Community departments. My main task was to create developer relations, focused on open source communities (I know, it’s a dream job!)
The imbalance between contribution and consumption of open source, especially within infrastructure (which business depends upon) is always a risk for the ecosystem. So the question is, what does a company and an open source project have in common?
The answer is humans.
There are many legal issues that makes it hard for a for-profit company to run a fellowship program. This differs from country to country because laws differ from country to country. Germany has a lot of protections in place for workers. As my human resource department told me: “If it smells like a job, it is a job.” That usually means taxes and expenses, and of course costs are always the major determining factor when launching a new program.
Unlike an internship, which implies you are training someone to be hired after the training period and, therefore, requires a pre-approved budget with a year’s salary accounted for. A fellowship, however, is a loose contract, closer to a scholarship, and only spans a specific amount of time. It’s a great fit for an open source project, and similar initiatives like the Google Summer of Code and Outreachy.
The model I was proposing was focused on the humans. I wanted to facilitate entry into the field for aspiring local technologists. I’d gone through similar programs myself, and I knew how frustrating they could be. They’re competitive, and to have a hope of being selected you had to commit to months of unpaid work prior to the application process.
By creating several small local initiatives, I believed the whole open source ecosystem could benefit. I felt that lowering the barriers to entry by not being so competitive, and making the application process easier, would surely bring more people in, especially the ones unable to commit to months of unpaid work.
The Open Source Community Fellowship is a six months paid program that connects for-profit organizations with open source projects to foster diversity in contribution and governance in open source.
Having employees as mentors decreases the cost of the program, and brings a huge value to a company because it helps train employees as better mentors to others. Several studies prove the benefit of having formal and informal mentorship within companies, with rewards including a sense of belonging, and it tends to result in retaining talent. Many companies say their employees are expected to have mentorship skills in order to achieve senior levels, but it’s a skill that needs to be put into practice. By giving employees 2 hours a week to acquire this skill, very little work is lost for a lot of benefit for the long term.
The open source project a business connects with needs to be critical for the business. If you’re going to pay a certain number of people to work for six months exclusively on a project, then there needs to be obvious benefit from that expenditure. I encourage fellowships to be an interdisciplinary program, because most open source projects need help in documentation, translation, design, and community support.
And yes, a fellowship should be six months, no less. Programs that offer only three months, maybe with a stipend, isn’t enough for a proper on-boarding and commitment. The maintainers of tomorrow need to be integrated in the communities of today, and that takes time.
Lastly, yes it has to be a paid program. We need sponsorship, not just mentorship. Although mentorship helps you increase networking, we all have bills to pay. Paying fellows a salary allows them to truly commit to the project.
Sauce Labs is sponsoring for the first time the program that started in December 2022 with five fellows across the USA. We hope this becomes a program that exemplifies the soul of the free software movement, so you can fork it, modify it, and redistribute it.
You’ve got the power
We’re often faced with the question, “What can I do?” Instead of feeling overwhelmed by difficulties that will always exist, acknowledge all the power you have in your current situation. Here are some ideas based on my own story:
- Become a community organizer. No groups near by? Create your own, and others will follow. Support is needed.
- Become a mentor. Join initiatives or create a formal or informal program at your company.
- Pay attention to your colleagues, and proactively offer your help. Even with a steady job, you still need help to grow. Use your privilege to get all the voices heard in your the meetings.
- Adopt a fellowship program to call your own. It’s a replicable model, easy to implement, and it brings innumerable benefits to the open source ecosystem.
There’s always something we can do to make the world around us a little better, and you are an important piece of that.