In 2009, when Sarah Mei and I started teaching free coding workshops for women, we didn’t expect to fix the industry, just our little corner of it.

We’re programmers. We solve problems by focusing on something concrete that can be built with the tools at hand. We focused on increasing diversity in the SF Ruby meetup. By teaching workshops, engaging the local tech companies and all of the people who wanted to help, we moved the needle. Later we expanded to include outreach to other demographics who are underrepresented in tech (which turns out to be most people).

Last week I spoke at a Bridge Foundry event where we announced a new industry partner program. In preparing for this announcement, I spoke to Amanda Cooper (@MandaCoop) on our advisory board. She framed what we do as “you make the road by walking it.”

There was no clear path, but we had ideas that we thought could work. We did the work to implement our ideas. We took a data-driven approach to measuring impact. We open-sourced our process and materials. In doing the work, we created a path that others could follow. Or more accurately, inspired others to help create the path by walking it with us.

Over the years, I’ve watched students become senior software developers. I’ve seen how volunteering at the workshops has caused some ex-programmers to decide to become software engineers again. It’s not all about more diverse software developers — we want everyone to be able to learn these tech skills, if they want to. Coding skills are applicable across many disciplines and can be useful to simply understand the technology that people use every day.

Most students and volunteers are working software developers, and we’re seeing some particular problems in the tech industry where we think we can help.

Lack of good tech jobs

The tech industry has a diversity problem that goes well beyond the “pipeline” problem that can be address with skill training. There seem to be few workplaces where there is real opportunity to succeed based on individual skill and potential.

I believe that most companies genuinely want to create workplaces where people with the right skills and capabilities can deliver business impact. This should be very aligned with business goals. Unfortunately systemic bias gets in the way. There are patterns that need to and can be changed. There are bugs in the system that need to be fixed in order to attract and retain diverse talent.

I see some companies where the environment seems to be different. I hear about companies who want to do better. Help create the path by walking it with some folks who have a lot of experience solving these kinds of challenges: join the Bridge Foundry Industry Partner Program.


Traveler, there is no path.
The path is made by walking.

Traveller, the path is your tracks
And nothing more.
Traveller, there is no path
The path is made by walking.
By walking you make a path
And turning, you look back
At a way you will never tread again
Traveller, there is no road
Only wakes in the sea.

― Antonio Machado, Border of a Dream: Selected Poems

I write this as a privileged white cis woman, or at least that’s what I look like, with my blue hair, ivy league education and house in San Francisco. I have compound privilege, so what I describe below represents an easy life.

I work in the tech industry.

I started programming when I was twelve. My first commercial software was a Mac application. People bought our software and we sent them a box with a paper manual and some floppy disks. I thought sexism was something I would only experience from old men and young jerks. There were a lot of messed up things in the world, but on this point I thought my generation was cool.

Now I work on distributed systems. People fill out a web form and enter their credit card and then just start using our software. It runs 24×7 on computers all over the world.

We write good code. We have tests that run automatically when we change anything, and extra checklists when we make something new. We still write bugs, and even if our code were perfect, it runs on hardware that can fail. So we create data centers with redundant systems, and just in case there’s a storm or earthquake, we run some more copies of the software on the other side of the planet. We do all that work, and still, we prepare for a production outages — that’s what we call it when things are so bad that people will start noticing. It’s inevitable. It happens. In fact, it happens so much it’s routine. We prepare. We create systems to alert us as early warning signals, so we can do something to avert catastrophic failure.

No matter how much we prepare. No matter how hard we work. No matter how brilliant we are at writing code. It happens.

By the time there’s a production outage, We’ve already worked through all the solutions in the standard playbook and nothing worked. Maybe we’ve already looped in a few colleagues who happen to be awake or nearby. We start improvising. We try anything that is both fast and safe. As we pull in some experts, we hope we’ve written all the important things down.

Afterwards, we’ll do a root cause analysis. It could be a mistake we made 6 months ago that’s been quietly corrupting data. Maybe we made an incorrect assumption, or some other system changed and we weren’t notified. Sometimes we could have prevented the problem. Sometimes the root cause is entirely outside of our control.

Sexism is like a production outage.

We learn to expect it. We create systems that mitigate risk. We learn the rules. We study the written laws and policy, because we find that the unspoken rules we learned as kids don’t make any sense. Guidelines about appropriate behavior box us in so tightly we can’t actually get anything done. Sometimes you can ignore the rules.

If you have the privilege of working with men who will respect you, it can work pretty well to pretend these unwritten rules don’t exist. If you want to move to a new team or a new position, you make a judgement call: is the opportunity worth the risk?

There are places I won’t work. Being part of the next unicorn startup isn’t worth the kinds of production outages I would expect there — it’s too disruptive to get any work done.

To be successful in the software industry, we need to take risks — make new software, work with new teams. Men take risks too and can experience their own production outages. And I’m sure I can’t imagine your situation, but from what I’ve observed in the United States, there’s a class of privileged white cis men where failure is a sign of positive risk taking. For blacks and latinos, it seems that failure is more often perceived as failure, or condescendingly, as a lack of preparation that is not their fault. Asian men seem to have fewer production outages in their early careers, then at some point they stop advancing and hit the bamboo ceiling.

I’m not sure the tech industry is really worse than any other place to work, but it does seem different. I wonder if its because many of us were like me. I expected it to be different. When I encountered obstacles, I just worked harder. I thought everyone was held to the same high standards, but when I look back, I’m not sure that’s true. If you have to defend your ideas and plans more than your colleague, that slows you down. If you don’t ask permission, it’s more likely you will be held accountable for your failure, so you have to make sure you don’t fail. We need to take risks to do great things, but for some of us, there are more risks and the risks are bigger.

The “leaky pipeline” is well-documented. Through my own lived experience and hundreds of women I’ve known as fellow travelers in this strange world of the tech industry, I see patterns that seem to be invisible to most of my male colleagues. This metaphor of the effects of sexism as a production outage helps me develop strategies and advise other women when they face obstacles. If there is only one woman on a team, it’s hard to tell the difference between sexism and incompetence. Is she being treated differently? Did he just make a mistake? The research is interesting, but when it happens to you, it doesn’t matter. You can do root cause analysis later. Right now, you need to put your life on hold and deal with a production outage.

Jennifer Anastasoff served as the head of people for the United States Digital Service (USDS). She grew that organization from a small team of three to an office of over 200 people in just two years.

On today’s Friction Podcast, she talks with Bob Sutton about fixing government friction

I had been a Presidential Innovation Fellow in 2013, living through a government shutdown and witnessing the failure of Then hearing about the slow and steady work that revived it, over a matter of months to a functioning website that allowed people to signup for services that they needed.

Later, when I was at 18F, I collaborated with Jennifer on a few projects. We worked behind the scenes to bring stories of results to the tech folks in San Francisco and elsewhere across the country.

In those early days, before the USDS had a website, I don’t recall the formal statement of values that she talks about on the podcast. I worked closely with many of the folks at USDS and these values were evidenced in the work:

  • Hire and empower great people.
  • Find the truth, tell the truth.
  • Optimize for results, not optics.
  • Go where the work is.
  • Create momentum.

Maybe they were on the wall somewhere at USDS HQ when I was there for a meeting or just to unwind with people facing the same tough challenges. I do remember the hockey table and that room with the wires in the old townhouse where Teddy Rosevelt used to live with his family. Working in spaces where great history happened couldn’t feel more surreal than trying to figure out if it was really true that A/B testing was illegal.

In the interview, Jennifer talk about how people would say that “in government, we’re not allowed to break the rules…” However, a lot of time it was how the rules were interpreted: “if it doesn’t explicitly say something is possible, than it’s not possible. And that’s just not the case.”

But you can’t just reinterpret things by yourself. We needed technical folks who could work with lawyers and policy experts, doing the challenging work of figuring out a solution that would work and was legal. I have great respect and empathy for the government workers who would routinely say “no” out of fear. It is pretty scary to realize that something you might do in the normal course of your work might actually break a law, which could literally cause you or your boss to be called in front of Congress to explain your actions.

“There’s very little room in all of this for a hero narrative,” she says in the podcast. We accomplished much by giving credit to our government colleagues who stepped up and took a leadership role in this work. We were temporary employees. We could go back to our easy tech jobs, and these folks would need to continue the work. There’s a different kind of hero narrative, which requires each of us to step up in the moment, say the thing in the meeting that no one wants to say, or ask the naive question, or simply read a thousand pages of regulation until you find that one clause that let’s you do the thing. You perform the everyday heroics that let you try something new, and that sets a pattern for you and your colleagues, and future generations of government workers, to be empowered to effectively help the people they serve.

Jennifer Anastasoff is my kind of hero.

Listen to the full interview with Jennifer Anastasoff and hear about the everyday heroics of the how people really make history.

p.s. The work continues. Consider applying as an Innovation Fellow — deadline is July 6th!