This post was originally published on LinkedIn. Comments and likes should be made there – on the original post.
Access.
It’s a word representing a fundamental component of making things possible. If a farmer doesn’t have access to water, how can they grow anything?
So the word access embodies an important concept that is used in a lot of contexts. Is the building handicap accessible? Is there a grocery store accessible or is it a food desert? Is your website 508 compliant so blind people’s screen readers can access it? How many people can now afford to access healthcare under the Affordable Care Act? And so on. Without access, nothing else is possible.
In mainstream US culture, the concept of access in relation to women in technology is currently generally attributed to the beginning of a woman’s journey into technology. Access to materials, teachers, and resources to get a woman started seems to be what everyone thinks is missing if the overwhelming proliferation of women-led non-profits to introduce females to code is anything to go by. (That they aren’t for-profit ventures is a whole other post.)
It’s a tidy package. Men can rely on the “there aren’t any (qualified) candidates to hire” line to justify their ineptitude at attracting women developers. Society in general gets feel-good stories of women-led charities. Women are made to focus on teaching basic skills to newbies instead of their own professional development. Corporations get tax deductions for donations to 501c3’s instead of turning to high schools and colleges and asking: “Why are you so horrible at this and what are you going to do to improve?”
By making the lack of female coders problem about the on-boarding of women to technology instead of what comes after men have (brilliantly) bought themselves out of having to answer hard questions or doing the hard work of looking in the mirror and admitting that they are the problem. That it is, in fact, not the women who ‘fail’ them by not becoming coders they could hire who are the problem.
And hey, in a few years, the new spotlight issue will be why aren’t there more coders representing ethnic minorities, and we can start the “on-boarding is the problem” narrative all over again. Meanwhile, this round of women leaders who code will be burnt out and disillusioned. (Psst men: you probably won’t even have to convince them to become project managers to leave coding! Bonus points to you!) In fact, I bet they’ll be burnt out to the point where they won’t even be able to find a clickbait headline writer who will hold men/organizations/an industry accountable for letting all the women that current women leaders trained fade back into non-technical professions.
I could go on and on about how women coders disproportionate representation in the professional field is not an access-to-the-beginning issue, but many others have and will continue to elaborate on that better than I can. Many women are, rightfully, eloquently, and loudly pointing out that no, actually retention is a key issue too. I trust that they will repeat themselves until people start listening. But I won’t go on about all that right now.
What I want to talk about right now is the struggles technical women have getting access to technical systems at their jobs.
I, personally, don’t think there is any coincidence in the high proportion of women who are, and are becoming, front-end developers. Hint: no one has to give you a password to use a browser.
On the other hand to run a database query, deploy production code, or even be able to read the existing proprietary source code I need an authorized account. From (99% of the time) a man.
Now, I have had every advantage as a woman in technology that there possibly was to have (again, that’s another post). Maybe, that’s why this issue stands out to me so distinctly. So let me share the crispest, starkest story about access that I have to choose from to help you understand.
——
Some years ago, my latest project at my job required research on information that was best and only obtained by querying a relational database. I was not in a technical department at the time. The person who held the keys to access to that database was Dan Siroker. I didn’t know much about him except he was a hot shot previous Google employee who now worked for us. He was in a different department from me, he didn’t know me, and he was entrusted to keep this data safe. I was (relatively) young (24) and a woman.
So I decided the best approach was to write him an email explaining my project and its importance and the types of queries I would like him to run for me in order to facilitate the project. I didn’t ask for access to the database.
Why didn’t I ask for access? So many reasons. Partially because of personal experiences. For example, I had previously asked (in a different organization) for an account on a Linux server to be able to write images to a specific directory and had the male systems administrator (who I’d previously considered a friend) make me go through a humiliating conversation about how no I was not qualified to have root access to the server. Partially because of stories I’d heard from other women. Partially because I just cared about the work getting done, not how it got done. Partially because asking for something you need is really hard for a person like me who was raised as a girl and woman in US culture. Rejection and the possibility of rejection – also scary. He (Dan) had no reason to trust me and every reason not to. I wasn’t on his team, let alone in his department – even if I’d been a man my experiences had taught me by that point in my life that cross-department collaboration was rare. I could go on.
I knew I wasn’t going to get database access, so instead of asking for it I documented with as much detail as I could what I wanted and needed. The email started with the project description and then listed SQL queries I wanted him to run and an explanation for what the query was meant to do. I must have had 10-15 queries. I, of course, had no existing access so I had no idea what the schema was like so I made-up table names and field names and relationships that made sense to me.
I must have read, re-read, proofread, edited within an inch of its life, second guessed, had concrete reasoning for each section that I could defend, ensured my made up database schema names were used consistently, and overall focused on that email like my life depended on it. If some time-traveling historian ever clocks the amount of time I spent on that email (and worrying about how that email would be received!) I would not be surprised if they said it was three days of my life at fourteen hours each.
Finally, after multiple read-throughs where I didn’t change anything and terror in my gut, I hit send. And waited. Dan responded relatively quickly – probably within an hour. If I know myself at all I know I postponed opening the email response I got from Dan. I was sure I was going to have to apologize for something in my email requesting him to run the queries or he was going to say no and I was going to have to get my boss to talk to his boss or in some way this was going to go really badly. Finally, I opened it and read:
Do you just want database access?
To say I was stunned was an understatement. I’m sure I re-read it multiple times thinking my eyes were deceiving me. Yes! Yes, that would let me research iteratively and help me and help the organization and keep me from bugging him and just… it was the right answer. It was as easy for him as knowing I had a legitimate need and the SQL chops to use it.
To say that I have respect for Dan Siroker which knows almost no bounds after that is an understatement. (He is, by the way, known as a hot shot for good reasons.)
I got the database access. I did my job. I didn’t break anything. (!!!) The organization succeeded in it’s mission. Life went on.
And I got a puzzle piece to realizing just because it’s important to prepare for the worst in people doesn’t mean I should expect it or be willing to put up with it.
——
I told you that story, instead of one of the ones where I was denied access, because it highlights how deep my belief that I wouldn’t get access truly was. Beliefs that entrenched don’t come out of nowhere. It also gives a great example of how a situation like that should be treated and dealt with.
On the days when I get so very, very frustrated with men in my professional field Dan is one of the good guys I think about when I close my eyes and take a deep breath. I’m very fortunate to have known more than my share of these technical good guys. They do in fact exist, and when I’m 120 years old I’m still going to remember every single one of their names with a smile on my face. If I may borrow from and channel the voice of Rev. Dr. Martin Luther King, Jr. for a moment:
I have a dream that one day women will find it easier to remember the names of the men who hindered them instead of those men who supported them.
To my fellow women reading this and getting depressed that it’s not just you being denied the access you need to do your job, I leave you with these thoughts: Would they be guarding accounts, credentials, and passwords so tightly if they thought we would prove ourselves fools? I don’t think they would be. I think our male delayers know deep-down that once we have access to a system we will have the last thing they are required for and we can figure out the rest by ourselves should it come to that.
If they were really worried we would break something, they would teach us how not to break it. If they don’t have time to teach us they would tell us what certification to earn, what to read, or what examples to go build to make us qualified. If the system is so shaky and sensitive that giving someone else access is too risky then they are just admitting how horrible of an engineer they are. If the data is so highly sensitive then why are they storing it in the first place, why do they have access to it, and what is the qualifying, objective criteria to be given access to it?
I think men know women are going to surpass them by so much that their fear gives them no choice but to unethically withhold the next stair of our staircase: systems access.
——
By the way: Dan Siroker – he went on to co-found Optimizely (the gold standard A/B testing platform) where he is now also CEO.
Author’s Notes:
- You can ask me questions at Wiselike.com/Alison-Stanton.
- If you’re in Chicago, consider attending one of the Ally Skills Workshops that I’m holding. RSVPs required: Workshops at Enova (Chicago),Workshops at Braintree (Chicago). If you aren’t in Chicago but want to attend or hold an Ally Skills Workshop, please contact me.