Playing the Long Game

If you’re familiar with research on survivorship bias, then you’ve seen this picture.

During World War 2, when planes returned from missions over enemy territory, they were riddled with bullet holes. The red dots represent where the planes were most hit.

As the story goes, the Center for Naval Analyses proposed increasing the armor in those red patches until a statistician named Abraham Wald pointed out that they were thinking about it backwards. Planes that got hit in the areas without the red dots were the planes that never made it home. If the Navy were going to put armor anywhere on new planes, it should be in areas without the red dots.

Obvious now, but a story worth retelling. Because...

If we care about increasing diversity in engineering, we need to ask women who never considered software development why they didn’t. And we need to armor up wherever those answers point.

While I haven’t yet published my findings in The New England Journal of Medicine, I’ve spent the last twenty years researching exactly this question... in the most annoying way possible... with a sample size of one-- my wife. I’ve changed her name in this piece to protect her identity.

The Need for Meaning

My wife “Mariam” (totally her real name) studied and practiced law. And she was damn good at it.  

She chose her profession because she wanted to-- and I quote-- “solve meaningful problems” and “contribute to creating a better world.” And yes, she saw law as giving her agency in service of her moral ambitions. Her early life choices were-- and are-- consistent with those of equally talented women who, in unusually large numbers, tend to pursue careers in healthcare and the social sector, education and the world of nonprofits. These are early life choices that are intentionally purposeful, that elevate meaning, that allow the more emotionally intelligent among us-- women and men-- to live their values.  

To young women like Mariam-- who intern for Amnesty International, who think about their professions as the counterweight to injustice-- software engineering isn’t an option today. And banking? Forgetaboutit.  

And-- as I’ll argue later in this piece-- young people concerned with social justice are exactly the kind of talent we need in banking and technology.

So question #1 for big-picture, longer-arc diversity champions: how can we frame software development and banking technology in a way that effectively and authentically signals meaning to young women? And maybe even younger than “young women”-- when they’re still kids in elementary and middle school.  

(This is where we take a moment and just thank God that the Amnesty Internationals of the world— the Children’s Defense Funds of the world— lack fundraising skills, because if they could hire every Mariam.... [Shiver])

By the way, despite what my sense of humor might convey, I actually think of banking and banking tech as meaningful, impactful, moral work… or I wouldn’t be here. The truth is that minus the work we do, there would be little to no global commerce, fewer jobs and fewer Mom-n-Pop businesses, more insecurity of every kind (from food to energy to cyber), less entrepreneurship and therefore less innovation, and even less philanthropy. If you don’t believe me, google “illiquid markets and The Great Depression” or watch the Cormac McCarthy film The Road -- a documentary about what happens when banks fail.

The Need for Mastery

As “Mariam” will tell you, I like to dress in a white lab coat— with a beaker in each hand— and ask her scientific questions. You know - for my research. My most penetrating questions usually revolve around how much she thinks a computer programmer’s life is spent doing math.

Back in year one, her answer was “your profession has the word computer in it… Of course you do a lot of math.” By year two— and without the application of electric shocks— she knew better.  

I personally struggle with basic arithmetic. You know how some people have anxiety attacks in the beginning of Star Wars movies because they’re afraid that the text will scroll faster than they can read?  Well, I have the math version of that. And it’s not mild math trauma. It's math PTSD. Two words: grad school. Two more words: save yourself the money. 

I actually love(!) computers because the whole point of them is that they do the computing-- the math-- for you.

So question #2 for big-picture, longer-arc diversity champions: how do we pop the persistent myth that software engineering is inextricably tied to the mastery of math? And while we’re at it, how do we kill the idea that you have to study computer science in high school or college to become a programmer?

(I for one am completely self-taught. Computer hacking skills. Nunchuck skills. Bow hunting skills. But I brag.)

Note: you might be thinking “isnt the M in STEM math?” Um. Yes. But I’m not aiming to increase diversity in all the STEM fields-- just software engineering, my profession. The other fields can write their own insightful pieces… and fight me for the talent!  

(Did I mention my nunchuck skills?)

The Need for Connection

Question #3 for us-- and I think this applies far more broadly than my narrow little world of software development practices: why insist on rigid, old-school processes that demand we work solo when we’re fundamentally better together?

The concern here is not that “Mariam” needs connection or that women are drawn to fields that stress connection. It would be lame to frame this as a gender thing when it's actually a mental health thing.  

We-- as leaders-- have been slow to recognize that the current process of building software-- the actual engineering, the fingers-on-keyboard practice, the day-to-day sausage-making-- needs to radically transform before substantial progress can be made in attracting and retaining healthy minds.

And that's rich... because software leadership-- as a mindset-- takes enormous pride in disrupting other people's industries... when the foundation upon which we've built our own discipline itself needs exactly that kind of re-do. Seriously. How do we write code today? We get requirements from someone, usually the business. We whiteboard the architecture and approach, usually as a team. We break down the requirements into single-developer-sized pieces. We articulate how those pieces need to interact with each other (service contracts). And we distribute the componentized pieces to individual developers, each of whom goes back to their desks, does some research and eventually starts coding. While there is collaboration in this model (the whiteboarding, the articulation of service contracts, code reviews, etc), it essentially ends with an engineer sitting by themselves with their headphones on, listening to music and coding. Software engineering today is a process which rewards that final solo act; a process that defines rock stars by how well they produce code when left alone.

Seen through this context, legacy development practices encourage the hoarding of red staplers. The engineering discipline at the core of our life's work is needlessly antisocial and psychologically isolating. I’m surprised that we haven’t yet traded in our open offices for monasteries.  

Many developers-- regardless of gender-- struggle with this. Some call it "bro culture." But that misdiagnoses the core problem as being about entitled jerks... which... isn't exactly false (they are, after all, Silicon Valley's second biggest export). But that view fails to indict the underlying, alienating practice of software engineering itself.

So-- I'm happy to say-- we have an opportunity! In the vernacular of peacetime CIOs, engineering culture is ripe for disruption. In the vernacular of wartime CIOs, it's a burning platform.

Especially since the talent that our field needs the most-- people with strong empathic muscles-- have an amplified sensitivity to these risks. The “Mariams” of the world start with higher EQ— which is why we need them and what makes them perfect for coding— but it also means that they understand that a life in software engineering means high levels of anxiety, a deterioration of confidence and an unhealthy focus on blame -- all of which they would correctly argue leads to persistent underachievement.  

Which all begs the question-- what's our profession's version of "Physician, heal thyself?"

[Wait for it.]

Developer, Debug Thyself - A Blog Within a Blog (Skip to the next section if you’re not a leader in tech)

Enter pair programming. We’ve all been exposed to it at some point (usually via agile initiatives and/or extreme programming) but how many of us have thought about it within the context of gender dynamics and the future of diversity?

[Crickets]

Fine. I think of pairing as an important, central piece in the transformation of software engineering as a discipline. And one that will make or break our aspirations for more diversity in banking technology.

If you’re unfamiliar, pairing demands that you work side-by-side at one computer for hours on end, continuously collaborating on the same code. 

• It diffuses the stress of being the single point of failure. 
• It helps validate each contributor’s strengths and builds confidence. 
• It sidesteps the language of shame.

And it's not just about the future. Let’s be honest. When you’re a successful woman with hands-on engineering skills and you have to choose between a firm that codes the old way (and rewards its old-school rock stars) or codes this new more collaborative way…. why would you choose the former? It’s shag carpeting. Smells musty.

Note: there are non-gender-specific benefits to pairing that a theoretical, arm's-length understanding won’t get you:

• Pairing uses social engineering to disrupt Parkinson’s Law. As I mentioned earlier, in the current solo-coder model, every engineer goes back to their desk, does some research and eventually starts coding. The key word there is eventually. The engineer knows how long they have before they need to finish their piece and unless they’re incredibly disciplined, human nature kicks in. Just like the college essay due next Friday, they get to it… when they get to it.  If you’ve ever paired, you know that the process sucker-punches procrastination. Collaborating on every line of code doesn’t happen unless you’re completely present. So pairing is the closest thing engineers have to mindfulness training -- minus yoga pants.  And good pairing cultures take that a step further by switching around who you pair with every couple of days. At that point, you don’t even need one disciplined person per pair. Motivational inertia takes over. 
• Pairing will suck the life out of classically introverted engineers (unless you limit the work-day to a maximum of 8 hours). Once you understand that extroverts charge their batteries via social engagement and that introverts drain them via social engagement, then you quickly realize that pairing needs to be handled with extreme care; especially in talent pools like engineering that have disproportionate representation of introverts.  There is no “working late.” If you don’t head home to decompress and recharge, you’ll burn out in two weeks.
• Pairing has an almost singular, cult-like focus on collective code ownership. Every sentence starts with “we.” By default you accept ownership of your partner’s work if for no other reason than it’s impossible to distinguish it from your work. Even if the tone turns negative (“We screwed up the design”), both partners own it. There’s no shaming or blaming. And any anxiety is about how to get the code past the problem.

And finally, a warning: pairing isn’t necessarily effective with your existing bench of engineers. Unless you’re hiring fresh talent, you’ll need to vet your existing engineers. On what, you ask? There are subtle and interesting differences in how male-male, male-female and female-female pairs communicate and a pair’s compatibility seems largely dependent on each participant’s ability to empathize with their partner. Given that a pair’s cohesiveness helps determine the quality of their output, the two most important skills are empathy and communications (not technical strength).  

Back to the Main Blog for More Mansplainin’

If we are to have a chance at convincing the next generation of Mariams to consider us as a career, we need to start waaaaay earlier and focus on meaning, mastery and connection. And we need to saturate the media with more accurate, empowering narratives about the impact of technology and banking.

With my Dad hat on, I’ll say it doesn’t help that right now-- culturally-- our children’s only exposure to the impact of software is through a media narrative that frames it as the way to become a billionaire. That might be compelling to that alpha-predator kid no one likes (and who will make us all pay one day!) but it’s not compelling to the kids that have moral ambition.  And banking technology needs exactly those kids.  

[Exhale]

I tried to stay away from the usual conversations about diversity in this piece. It doesn’t mean that I don’t care about them.  

It’s now commonplace across the banking industry to have progressive HR policies and practices that focus on:

• training managers and senior executives on the challenges of implicit bias;
• increasing the percentage of diverse applicants in the talent pipelines that hiring managers review;
• pairing diverse up-and-comers with supportive senior mentors and sponsor; and
• changing internal promotion processes to highlight equally-qualified but underrepresented groups (the idea being that diverse candidates need to see more faces like theirs in the ranks of senior leadership).

These are all good and worthwhile efforts, as are all the internal social networks that we continue to drive. AND these strategies need to be supplemented with investments in getting more diverse populations interested in our field earlier.  

Our challenge today is that the talent of tomorrow needs our core engineering discipline to change; to be intentionally purposeful, to demystify mastery and to become more cooperative and to facilitate connection. And again, that’s not to attract women-- but to attract, retain and grow diverse, healthy, ambitious, open minds. 

Our new model of working needs to replace its calcified reliance on solo coding with a collaborative process; one that needs to deliver better/faster code by supplementing a traditionally left-brain activity with right brain strengths.

In my experience-- and I write and talk about this frequently-- great engineering is what happens when we build rapport and trust, when we engage in networking and relationship building, when we invest time to be well-connected and to think of others.  

In other words, great engineering is an exercise in empathy.

Let’s make sure kids the world over understand that. So we don’t risk having a future with even more lawyers. 

(I will regret that last sentence.)

(I love you M!)