My Equal Pay Day Gripe

I don't get a lot of the trimmings around Equal Pay Day. I get acknowledging it, protesting for it, lobbying your representative, pushing to hire more women, underrepresented minorities, and the historically marginalized. But I have a big gripe with it:

It's a red herring. Pay equity, while valuable in and of itself, distracts from the larger issue of representation. Guess where we have racial pay equity? The US presidency. Want to get equal pay on a Forbes 500 C-level board? Don't hire any women. It's easy to take a large pool of women in a company, increase their pay by 5-15%, and then let them languish at the entry levels. But having a C-suite that reflects the population? Bringing underrepresented people into proportional representation at all levels of a company? That requires structural change. Representation in tech, for instance, entered the zeitgeist in the last decade. Since then, most major tech companies have achieved something like pay equity. But despite all the hand-wringing over the pipeline, the actual representation numbers have moved exactly zero. Because that's hard to solve. Much harder than pay equity. So, equal pay. Good first step. But just a step.

My second gripe is, of course, that the gaps in pay equity still suck. That it takes until April 10th for women in general, July 31st for black women, September 25th for Native American women, and November 2nd (coincidence, anyone? GOTV!) for Latinas. 

I’m lucky, and not in a Jeffersonian, “I make my own luck” way. Math and reading came easily to me, I lived in a decent school district, attended community college when it was still basically free, earned a CS degree without understanding much about its value. And that was a cascade of semi-random events that has allowed me to be one lucky Latina who has vaulted the pay gap.

Neither my path nor anyone else's is wholly reproducible. But I can share a couple things that were within my control and can yield step-function changes.

1) It’s been said before, but: negotiate! Negotiate hard. Never take the first number. Never give the first number. Try (and all you can do is try) to set aside the messages you’ve been receiving since you were small that you’re not good enough. Not worth it. That your partner's income is more important anyway. That you don’t meet 100% of the job description. If you feel like you’re being a bit of a jerk in negotiations, you’re probably doing it right.

2) Find a sponsor. A sponsor is different from a mentor. A mentor will guide you. A mentor is great for an outside perspective. But a sponsor will grab you by the hand and pull you up the ladder. They will lobby for your promotion, connect you with the people who will give you the stretch opportunities, advocate for you, actively. How do you find or identify this person? Sometimes it's a mentor who sees your potential. Often it's a boss you've impressed. But just as often you have to ask. Ask for the connections, ask if they know of any good roles out there. Ask if they feel you're ready for a stretch role. And once you find them, give back, help your sponsor out. Point good candidates their way. Pitch in on their projects. These relationships pay dividends, so invest in them.

Good luck out there.

An Essay on the Seattle Symphony on Representation

I got a call Thursday from the Seattle Symphony. It's their annual fund drive and I've been donating every year for several years now. I like the symphony, unapologetically and lavishly, even though it's a little fusty and I get that classical music is a niche interest, closer to polo than anything else in the zeitgeist. People assume I must've been forced to play the violin when I was younger but no my parents weren't those kind of immigrants. I started listening to public classical radio as a kid and have been hooked ever since. Even when I went through a late 90s punk phase and shaved my hair, I still spun Varese in the evenings. So I'm a lifelong fan. And back when I was fresh out of college and struggling to pay off my student loans and trying make it in a new city, I could get a third tier seat for $14.00 and experience world class art for an evening and forget about my problems. The symphony has had my loyalty ever since.


I wasn't feeling well when the fundraiser called. I was sick and in a bad mood. She gave me the usual spiel about how donations keep the lights on and they do lots of community outreach and I was ready to give my usual amount when I decided to be a bit combative and ask, "So does this outreach affect communities of color at all? Who gets access to this work?" And I said this expecting a boiler plate #AllCommunitiesMatter-style answer which really means "rich kids in Ballard get the symphony brought to them." and I would have sighed and that would've been that.

But she paused and said "You know I've been told I can say this, because this is very important to me," and then I proceeded to get schooled. Thoroughly. Arts funding in Seattle is uneven and, as you might guess, tends to be highest in the neighborhoods that already have money. The Seattle Symphony provides classes, instruments, and teachers to schools in Rainier Valley, Othello, Columbia City, White Center, and other historically black and brown neighborhoods that wouldn't otherwise have music education of this caliber. At the end of the course, students are invited to play a concert at Benaroya Hall. And the Symphony travels to these neighborhoods to provide free community concerts. Where local government has stepped out, the Symphony has stepped in. She is black and her husband is Latino and their daughter is part of this program now and she could personally attest to the direct impact the symphony has in the community. We talked about how very very few people in the audience look like us, and how we want to see more people who look like us. By the end of the call I was crying a little because I've never met another person who understands both how much the symphony can mean to us personally, and how much we want to see it be accessible to people of color. In 30 years, when I'm still attending, I hope to see an audience that looks like the full spectrum of Seattle because arts are for everyone, not just for art's sake, but because a well-rounded education is critical to lifting communities and breaking down socio-economic barriers.

So, Seattle Symphony, I didn't get the name of the woman who called me. I regret that, because she was such an eloquent advocate for the work that you're doing and she reversed my perspective on the symphony's outreach. Please talk more about the work you do for communities of color in Seattle. Or better yet, make her your spokesperson for it.

Putting the 'T' in TPM

From a March 2015 article for the Seattle Girl Geek Dinners blog


Technical Program/Project Manager is a relatively new job title compared to the more ubiquitous management titles that we see in the tech world: Project Manager, Product Manager, and Program Manager. The titles can be interchangeable depending on how your company defines the role, so this article will generally apply to many [Fill in the Blank] Managers who work on software projects and aren’t exclusively business focused, and for ease of discussion, I’ll refer to all of the above as T/PMs.

One question that I’m often asked by people who are thinking of becoming a T/PM is: “How technical do I need to be?” This is usually from more business-oriented folks who are thinking about taking the TPM route, and sometimes (but less often) from developers who are looking to move into management-oriented roles.

The short answer would be: just technical enough to get the job done.

The longer answer is that there are different areas of knowledge you’ll need. This will probably be the most controversial stance I take here, but it is my personal opinion that it helps a ton to have cut your teeth working as a professional developer for 1–2 years before considering transitioning to the T/PM role. Does this mean it’s impossible to become a T/PM without professional development experience? Not at all. If you’ve programmed in your spare time, done college projects, or have a degree in a technical field you have a good amount of preparation. I also know that there are excellent T/PMs out there with no programming experience! I have just personally found that it makes the job much easier (then again, I don’t know how hard the job is without a development background). Regardless, you’ll likely need some hands-on experience with:


Have you designed and implemented APIs (Application Program Interfaces) before? Can you read an API spec comfortably? APIs are the primary way that two disparate pieces of code or functions communicate with each other. Understanding how APIs work and when they are used is vital to being a T/PM since so much of the job is teasing out dependencies that your project will have on other systems.


Technical specifications are T/PM bread and butter. At a high level, they describe and define the behavior of systems. In application, they will tell you information such as how your data needs to be structured to be consumed by a system, or what functions you need to implement if you choose to use a given interface. They will help you understand how to use a new framework. You will write them to help create new software and to help others use your software. Sometimes you will write specs to sell someone else on something that you want to build. Get comfortable reading and writing in this area.


Building software requires hardware, so understanding basic client-server architecture, deployment, the OSI stack, and hardware constraints is incredibly helpful. Plus it’s possible that you will be responsible for provisioning resources for your team.


As a T/PM, fluency in data, how it is structured, how it is stored, how it is extracted, and how it is used is important. From the technical side, you’ll likely have to help define data models, and from the business perspective, you’ll define success and/or operational metrics — it will be up to you to monitor, report, and respond to changes in the data.


This is not exactly technical, but since it’s a keystone T/PM skill, I feel that it should be called out. Being the intermediary between business and development is one of the core features of the T/PM role: That means having equal fluency when talking to Product, Marketing, Finance as you do when talking to Engineering or Operations so that you can help each domain understand the other.