Girls in Tech closes its doors after 17 years

Our hiring practices actively surfaced people who had difficulty being considered and retained on other teams and at other companies.

This concept of being inclusive is a lot different than having biases. We didn’t reject men or anything like that, we just made ourselves more visible to underrepresented candidates and hired on very specific personality traits on top of the technical requirements. We also made it clear to candidates that our team was accepting and empowering to people in minority groups as they relate to our industry.

For example, we would use specific interview questions to screen out people who were selfish, egotistical, and closed-minded. There would be a zero or low chance of hiring someone who would make our minority team members uncomfortable and lead them to quit because those people would have been screened out.

Another example was being open to diverse backgrounds, like transitioning from a different team within the company or having a resume that lacked formal schooling.

I remember a conversation that stuck with me where the Black woman on our team told me about how she tended to job hop because she could only stay at a company so long before she started to have difficulty tolerating how she was treated by everyone else in the company. As someone who isn’t a minority in my industry it was a very eye-opening thing to hear. I had never once quit because of the way people treated me on a personal level! I had always quit for job reasons like pay, quality of my projects, effectiveness of my managers.

So, you’re right about random chance and statistics, but in my opinion a good team won’t allow random chance to dictate their candidate pool. In my opinion a good team that approaches 10 people will notice the fact that there are zero women and question whether they have made their team a good place for women to work for in the first place.

Let’s not forget that diversity is a proven dollars and cents benefit to corporations. Conservative media right now is using “DEI” as a substitute for racial slurs, but their intended audience for those insults isn’t corporate board rooms. No, Disney isn’t a liberal corporation, they just have a policy of inclusivity to the point of being perceived as overdoing it because they know that including everyone means a larger employee candidate pool and a larger customer pool.

When you say “You don’t need to actively be inclusive if the problem is solved,” the problem with that argument is that the problem is so obviously not solved. You can’t look at various outcome statistics for the racial demographics of the US or the gender pay gap statistics and tell me with a straight face that the problem is solved.

The people who have the power to make those outcomes more equitable are institutions like schools and employers. That’s why I prefer my employer to be active rather than passive.

(I have a hard time believing on-call is a reason why women don’t join SRE teams, especially considering that nursing has the opposite gender bias and also has far worse scheduling woes than any SRE on-call schedule I’ve ever witnessed or heard of)

Put another way, there aren't enough qualified candidates outside expensive cities and therefore the salaries typically tend to go up to cover those costs of living.

Firstly, I have a news for you: avoiding interruptions is not something special to developers. It's the case for ALL EMPLOYEES, even the ones that have more contact with people. The complexity of the flow may vary between employees, but it's just ego-inflated bs when devs are painting themselves as such snowflake beautiful minds with their so special workflow. There is a very strange mentality of developers not being able to do what other people in the company are able to manage and they therefore need to invent that they are "special".

Secondly, many devs are shit at being able to tell if a meeting is useful or not. I saw very good dev teams, I also saw dev teams where we reduced the amount of meetings and where they started producing useless code that did not do what was needed, while at the same time, some of those devs were saying "see, less meeting, now we deliver twice faster" without even realizing that the useful outputs were twice slower because of all the things that needed to be redone. Unsurprisingly, the number of meetings re-increased and some adults had to supervise the team more closely to make sure they understood what was needed. And of course, some of those devs were complaining, while being totally incapable to even conceived that their twice-faster delivery did not matter if they delivered the wrong output.

So, yeah, NO ONE HERE IS PRETENDING THAT WE SHOULD HAVE USELESS MEETINGS. Simply, I'm pretty sure that some meetings that you consider useless are in fact very useful but your "I-just-generate-code-I-don't-need-to-exchange-with-people-to-understand-what-is-needed" mentality makes you unable to notice it.

And again, while there is some truth and things to learn behind the "maker schedule interruption problem", a lot of devs complaining about it are just people who are not good at their job because they lack basic skills that are required. I'm a scientist working in R&D for a private company. I'm working with devs, I even sometimes write full modules that end up in production (it should be done by proper devs, but I'm stepping in to fill the gaps). Trust me, I know very well the "maker schedule interruption problem" and it is indeed a tricky balance. But the reality is that I see some devs who are working on things way less complicated than me and having way less meeting than me who are using the "maker schedule interruption problem" to justify that they should not do a part of their job (yes, going to the meeting to align your work with the company needs is YOUR responsibility). I'm doing things that require juggling with complicated things in my mind all the time, and yet I'm able to go to these meetings without much problem. If they cannot, it's not the meeting the problem, it's them unable to manage.

When you suffer from the "maker schedule interruption problem", your first reaction should be: "is it because I should learn to work better with interruptions?" followed by "I should try to understand why these meetings exists, in an intellectually honest way", and not "I'm a developer, I'm special, the world revolves around me and if I don't like it, it means it's useless".

To come back to the subject: this is yet another good example of the divergence of what software development intrinsically is and what the software developers invent it is. Software development requires interacting with people, software development requires to be good at managing interruption. Somehow, software developers have invented, probably based on TV show clichés and teenager nerd mentality, that software development is just limited to them playing around with code.