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.