Changing tech, one conversation at a time.

How to use organizing tactics to talk to co-workers about pushing for change in technology companies.

Andrew Reid
7 min readAug 1, 2020
Two women have a workplace conversation.
Photo by Christina @ wocintechchat.com on Unsplash

A substantial amount of virtual ink has been spilled over the problems facing and caused by large technology companies. Hands have been wrung. Brows have been furrowed. Members of Congress have done whatever this is.

I’m not interested in litigating these issues in this space (at least, not today), but just so we’re all on the same page I’m talking about things like:

  • Workplace cultures that tolerate microaggressions
  • A lack of diversity, particularly among upper management and boards of directors
  • Privacy and digital security concerns
  • Algorithmic bias
  • Employee rights (Yes, “subcontractors” should count as employees)
  • Rampant online hate, harassment, and discrimination
  • Elon Musk’s Twitter account

These issues persist despite the fact that many software engineers are actually compassionate people with progressive values who care about making the world a better place. We talk about things like developer empathy, advocate for pushing code to the main branch instead of master, and design UIs with accessibility in mind. Many of us still believe in not being evil.

So how do we as engineers change things in our companies? How do we even begin taking on systemic problems while we’re working from our hastily reconfigured spare bedrooms due to the pandemic? How do small groups of people with limited individual power change the world?

Take cues from historical change movements

To start, we invoke our inner Margret Mead and recognize that small groups of thoughtful, committed people are the only thing that has ever changed the world.

Be it postal workers striking for maternity leave in Canada, the Selma marchers enduring Bull Connor, or agricultural workers taking their struggle for respect from the fields to the supermarket, small groups of committed people are at the genesis of every movement that has pushed the moral arc of the universe towards justice.

At the core of each of these historical movements was a set of organizing conversations. Every recruit to these movements had to be convinced by someone else that the movement was necessary, could reasonably be expected to achieve victory, and required that recruit to immediately sign up.

These types of conversations are exactly the types of conversations that we as developers can have with our colleagues. Each convert to a cause increases the power that can be wielded to address it. Conversation by conversation, it’s possible to build a change movement inside large technology companies. As the noted social justice activist Fred Ross, Sr. wrote in his seminal Axioms for Organizers:

It isn’t hard to organize if you take it granule by granule, brick by brick.

So how do we have these conversations with our colleagues? I’m glad I asked.

A framework for conversations with coworkers

In my years organizing healthcare workers and public school teachers, I found myself frequently having conversations using a framework developed by Marshall Ganz.

Ganz helped organize the previously referenced Delano strike and grape boycott and was also involved in the Mississippi Freedom Summer, SNCC, multiple labor organizing campaigns, and the 2008 Obama Campaign. He’s almost like a Forrest Gump of late 20th Century American organizing successes, except in this case Forrest has a Ph.D. and teaches at Harvard.

There are four key components to his framework.

Agitation

To recruit someone to a change movement, one must first push them out of the comfort zones into which we all naturally fall. One must inspire their righteous indignation, make them more angry than apathetic or afraid, and tap into their emotions. To quote Fred Ross, Sr. again:

A good organizer is a social arsonist who goes around setting people on fire.

In my experience (and that of talented organizers with whom I’ve worked) this can best be accomplished by asking questions. It’s the interpersonal equivalent of Toyota’s Five Whys approach to identifying the cause of a problem. Asking questions allows an organizer to identify what issues are actually of importance to someone. Open-ended questions, in particular, allow one to draw out issues and concerns. As a person’s individual issues are identified, an organizer can then tap into those issues to create the anger and emotion necessary for action.

One more note on agitation: we developers tend to be data-driven, number-loving, detail-oriented types. I obsess over the percentage of my code covered by tests, whether I’m returning a 400 or 404, and whether my JSON is correctly formatted with []’s and {}’s. That works against us here. The anger we are trying to inspire doesn’t come from statistics. It comes from stories.

Think about the emotional reaction created by learning that from 2009–2012 32% of people killed by police were black, but with a fatality 2.8 times higher than whites. Now compare that to the emotional reaction from learning that Breonna Taylor was sleeping peacefully in her home in the middle of the nights when cops mistakenly knocked down her door with a battering ram, shot her multiple times, and then didn’t bother to provide any medical attention to her as her life slipped away. Both should create some level of anger, but the details of Taylor’s murder make my blood boil every time I hear them.

Stories, not stats, make the impact we are looking for here. It likely comes as no surprise at this point, but Fred Ross has thoughts about this too:

To win the hearts and minds of people, forget the dry facts and statistics; tell them the stories that won you to the cause

Hope

The second component of this framework is hope. If people don’t believe change is possible, then they’ll believe there’s no point in doing anything. They’ll sink back into the apathy we just talked about overcoming. We can provide hope by providing a plan to win. This requires some forethought before starting to have organizing conversations, but that’s probably a wise idea anyway.

As software developers, this should seem familiar. We (hopefully) don’t build new features by walking into the office at 10 AM, dreaming up an idea, and immediately adding some code to production. We brainstorm the idea, go through cross-functional inception, find a place in the roadmap for that feature, write out user stories, add cards to a Trello board, make a new branch, write tests, and then pseudocode out an initial iteration. This results in good code because we ignored our inner cowboy and followed a plan.

Organizing works the same. If we have a plan to win, we’ll be more successful and we’ll inspire hope in those we try to recruit to our cause. That plan must be conveyed as part of an organizing conversation.

Urgency

Third, we must imbue our conversation with what Ross calls a “supreme sense of urgency.” Action that is not required immediately will not happen.

If a conversation is an equivalent of presenting someone with a Sev 4 issue at 4:00 on Friday afternoon, it’s unlikely any concrete action will come out of it. The conversation needs to be an “AWS has completely gone down in multiple regions” event. Verbal and non-verbal cues should be used. So should deadlines, even if they’re artificially created just to create this sense of urgency. Obviously, this should tie in with the plan to win. If the goal is to present management with a petition on Tuesday, the deadline can’t be set for Thursday.

You

Finally, an organizer must convey that the person’s involvement is crucial. Get a firm commitment. Push to make it happen. Ask “Can we count on you?” to take a specific action. Don’t avoid being direct. Don’t abandon the conversation without an answer. And don’t forget some of Ross’s best advice:

“Maybe” is a double, triple “No!”

Ross also cautions that 90% of organizing is following up with people after they’ve committed. There are times I’d argue that estimate is low, but I think he makes his point. As programmers, we’ve learned not to trust a passing test. Fire up a local server and try it manually. Run the code through CI/CD to make sure it works in a different environment. Try it in stage before production. Don’t just take “yes” for an answer. Follow up with people and reconfirm their commitments or they will forget.

Putting it all together

So that’s how to have an organizing conversation. Agitate around issues. Inspire hope with a plan to win. Create a sense of urgency. Convey that “you” is essential to the plan’s success and get a commitment.

This framework can be used to mobilize action on any issue. I’ve used it when talking to hospital housekeepers about striking for health insurance that allows them to use their own hospital. I’ve employed it when talking to voters about why they should support a particular issue. My wife claims she used it when trying to convince me we should date. When restaurants were still a thing, we both regularly employed it to advocate for our preferred cuisine on a Friday night.

Want to push your company to do more to promote diversity than a #BLM tweet? Think it’s time for a real conversation with management about how they are ignoring privacy concerns or publishing political ads completely untethered from the truth? This is a proven way to start on that road.

When it’s taken granule by granule, brick by brick, conversation by conversation, anyone can start a successful movement for change. When enough people are recruited to that movement through organizing conversations, their collective power can be harnessed to change the world. All of those problems* facing tech can be overcome with people power.

*OK. Maybe not Elon Musk’s Twitter.

This story was adapted from a lightning talk prepared for the Turing School of Software & Design.

--

--

Andrew Reid

Good cook | Experienced organizer | Decent programmer | Slow marathoner | Terrible woodworker