Privilege's upward-facing window.

Somewhat recently there was a Twitter thread that listed which universities had computer science graduates worth hiring, as well as the hirable percentage from those universities. The best ranked universities were small, famous and expensive.

Quite a few folks reacted against this perspective.

At least as many chimed in to confirm the claims.

I didn’t say anything – I stopped arguing on Twitter a long time ago – but I found myself discussing the thread with a few folks. Like me, the folks I chatted with hadn’t attended an elite private college, and unsurprisingly we disagreed with the take. Working in a somewhat status-oriented profession, I spent the early years of my career deliberately bulwarking my credentials against the perception that I was second tier, and to see that perception voiced so plainly brought back those memories.

From those private discussions, there are a couple of aspects that I think are worth digging into. First, that these lines of thinking generally mix signaling with success. Second, with privilege comes an obligation to work on yourself.

Signaling

The state of measuring software engineering productivity remains exceptionally weak, with many categories of work dismissed as unimportant because folks find them undesirable, even those essential to impactful teams. This self-serving transmutation of disliked work into low status work is a wedge that wrecks evaluation. (The most damaging variant is when folks recharacterize work they find difficult into low status work, recasting the hardest work as the least valuable.)

The exact slate of critical-but-unrewarded work depends on your particular environment, but I’ve seen teams that discredit the value of note-taking, event scheduling, user interviews, writing tests, planning – for any activity you believe is essential, there is a team out there that self-rates as extremely high performance and has decided that activity is total garbage.

This culminates in perceived performance having a strong signalling component that obscures actual performance. It’s extraordinarily hard to build consensus on an individual’s or team’s impact in such an environment.

If you’re willing to accept this assertion that the inputs into our performance evaluation model are imperfect, and combine that assertion with the underlying truth of training machine learning models – garbage in, garbage out – then it’s hard to be confident that we’re evaluating folks with much accuracy.

This observation applies to your performance calibration process and also to college programs. High status companies and programs certainly generate and perpetuate “signal-heavy” engineers, through their interview processes and performance processes, but we should be deeply skeptical of how those signals correlate with impact.

If you’re reading this and think it’s an uncommon oddity, it’s my experience that every single SRE and TPM organization invests considerable ongoing energy into managing the ramifications of this phenomenon. It’s also the lived experience of many of the women and underrepresented minorities that I’ve worked with, who are constantly calculating how to manage the intersections of signaling and unstated assumption.

Working on yourself

That said, I’m less bothered by the perspective’s flaws – in the spirit of the Hegelian dialectic, most perspectives are flawed representations of another more complete perspective – than the stubbornness in its defense. There’s a lot for each of us to learn, and we need to be engaged participants in learning it.

I grew up with immense privilege, and also some personal challenges. The presence of those personal challenges effectively blinded me from my privilege for a very long time, even though in retrospect my struggles were minor. It’s much easier to read Harrison Bergeron and reflect on how you’re being held down, rather than noticing how your success is paved with weights carried by others: weights that you’re culturally inculcated against noticing.

Over the last few years, I’ve started to view privilege as an “upward-facing window”, where you can crisply view the privilege of others who have more, but have to work deliberately to notice your own. I’ve even found my own memory suspect: I can vaguely remember being frustrated by folks exercising privileges that today I do exercise. It’s surprisingly easy to simultaneously forget those previous frustrations against something I’m currently doing, while looking angrily upward at someone else with a different privilege.

Noticing your privilege is a lot of work.

It would be rewarding to say that I was always thoughtful on this topic, but it took me a long time to grow confident enough in myself that I could allow myself to acknowledge the inequality that I benefit from. For me, self-confidence was a prerequisite to self-awareness, and I imagine it’s similar for many others.

In addition to self-confidence, I’ve also benefited immensely from my path into engineering management. Being a manager has slowly unlocked awareness for me, as I struggled to understand why folks I supported weren’t able to succeed with the same playbook I’d used. There can be an initial sense that they’re simply not implementing your advice properly, but over time it’s increasingly clear that the paths are unequal and unfair.

Noticing your privilege is a lot of work, work we’re obligated to do.

If you don’t have some grasp on your own privilege, you’ll struggle greatly to support others as an effective manager, inspire others as a leader, or contribute as a partner in your own life.

Often times when you’re having a discussion around privilege and signaling, particularly in the context of hiring, you’ll end up having a discussion around the “unimpeachable efficiency of bias”, where someone cedes the moral superiority of biased evaluation, but argues there isn’t a pursuable alternative.

I understand that perspective, and would have agreed with it at certain points. The path to doing better is to have a clear understanding of the behaviors and skills that make someone impactful in your organization and evaluating precisely for those skills.

Many interview processes are unclear about what they’re evaluating, and those are the most susceptible to testing for signaling over skills. The good news is that designing interview formats that effectively test the identified skills is a very mechanical skill that anyone can develop with practice: I’ve gotten to participate in several interview loop revamps that took that approach to good effect.

On the other hand, getting to clear alignment on what makes someone impactful at your organization, that’s really hard, and is the stuff of effective, courageous leadership.