The Decline of DEI Programs in High-Tech Leadership

Women Who Code shut down in April. Girls in Tech dissolved in August. Tech Talent Charter closed the same month. Three organizations that collectively supported hundreds of thousands of women and underrepresented people in tech—gone within five months of each other.

This isn’t a coincidence. It’s a pattern, and the data behind it is damning.

The Numbers #

DEI-related job postings declined 44% by mid-2023 compared to the prior year. By late 2023, the decline accelerated further. CNBC reported in December 2023 that Google, Meta, Zoom, and the company formerly known as Twitter all made significant cuts to their DEI teams and programs. Not trims. Cuts.

Crossing the Chasm: AI's Impact on Team Performance

Geoffrey Moore’s Crossing the Chasm came out in 1991. It describes what’s happening with AI adoption in engineering teams right now — with uncomfortable accuracy.

Here’s the framework: new technology gets adopted by innovators and early adopters (the enthusiasts), then hits a chasm. That’s the gap between early adoption and mainstream use that kills most products. Crossing it requires a fundamentally different approach — stop selling to enthusiasts and start solving a specific, painful problem for the pragmatic majority.

AI-Generated Code: The Trust and Verification Gap

There’s this moment I keep seeing on my team. An engineer gets a Copilot suggestion. It looks right. It passes the quick mental check. They tab-accept and move on.

Twenty minutes later, a test fails. The bug trace leads back to that accepted suggestion — a subtle null handling issue the generated code glossed over.

This happens more than anyone wants to admit. And it scales.

The paradox in numbers #

Three statistics that, taken together, should alarm anyone running an engineering org:

The Product Manager Role: Lessons from the PM Debate

New year. I want to talk about the most contentious debate I saw in tech this past year — and somehow it had nothing to do with AI.

At Figma’s Config 2023 conference back in June, Brian Chesky told the audience that Airbnb “got rid of the classic product management function.” The internet went nuts. PMs panicked. Founders cheered. Twitter threads stretched for days. Hot takes piled up like laundry nobody wanted to fold.

Learning to be a Great Leader is a Marathon, not a Sprint

I almost called this post “Leadership Lessons I Wish I’d Learned Sooner” — then realized that framing misses the entire point. The lessons aren’t late. They arrived exactly when I was ready to absorb them, which is the whole problem with leadership development: you can’t speed it up the way you speed up a code deployment.

I’ve managed engineering teams for the better part of a decade now. Small teams (3 people at Backer), distributed teams (9 engineers across 4 time zones at TaskRabbit), and DevRel teams at Google spanning multiple offices. The contexts differ wildly, but one pattern has been consistent: the leadership skills that matter most are the ones that resist being learned quickly.

Productivity: How to ship faster and on time

Managing both kinds of teams — on-time and perpetually late — taught me one thing above all. The talent gap between them ran roughly zero. The process gap ran enormous.

An uncomfortable truth in this industry: shipping speed ranks as a leadership problem far more than a technical one. Engineers love to blame late deliveries on “complexity” or “technical debt” or “scope creep,” and those factors are real enough. More often, nobody established clear boundaries around what “done” means, nobody surfaced blockers early enough, and nobody had the nerve to cut scope when reality diverged from the plan.

Finding the 6th Day: A Productivity Guide for Engineers

Here’s a number that keeps bugging me: the average engineer at a large tech company spends only 30-40% of their workweek on actual engineering work. The remaining hours vanish into meetings, Slack, email, context switching, and whatever passes for “alignment” this quarter.

That means in a 40-hour week, you’re getting maybe 16 hours of real output. Two full days, gone.

After years managing engineering teams — at TaskRabbit, at Google — the pattern holds consistent across companies, team sizes, and seniority levels. Smart people sit down to write code, get interrupted, attend a meeting that should have stayed a doc, get interrupted again; by 4pm the day has accomplished roughly nothing.

Psychological Safety in Knowledge Sharing

A few months into my time at Google, I watched a junior engineer ask a question in a team meeting that I thought was obvious. The answer was in the documentation—technically. It was covered in the onboarding guide—sort of. Three senior engineers had the answer off the top of their heads.

What struck me wasn’t the question. It was the silence before someone answered.

Two full seconds of silence where I could feel the junior engineer regretting asking.

Retaining Talent through Developer Experience (DevEx)

I lost good engineers to bad tooling—not once, but at every company where the build pipeline rotted and leadership shrugged.

Not officially, of course. The exit interview says “career growth” or “new opportunity”—the usual script. But in the months before departure, the complaints ran identical: slow CI, flaky tests, outdated docs, a deployment process requiring three manual steps and a Slack message to someone in another timezone. Death by a thousand paper cuts.

Socio-Technical Systems: Designing for Human Cohesion

In 1968, Melvin Conway submitted a paper with a claim that’s been haunting software engineering ever since: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Harvard Business Review rejected it. Not enough evidence, they said.

Fifty-two years later, every engineering leader I know treats it as a law of nature. Funny how that works.

We usually quote Conway as a warning. Your architecture will mirror your org chart whether you plan for it or not. But I’ve been thinking about it differently lately — if org structure determines system structure, then org design is architecture design. You can use that relationship intentionally.

Adaptability: The Core Engineering Skill for 2021

Nine months ago my entire team went remote overnight. Not the planned, phased, “let’s pilot this for a quarter” kind of remote. The kind where you close the office on a Friday and hope Zoom works on Monday.

Some engineers barely missed a beat. Others struggled for weeks. The difference wasn’t seniority or technical skill. It was how quickly they could rewire their working habits.

I keep coming back to that observation as 2020 wraps up.