Meet the Crew: Chad Humphries, Product Engineer

Chad spent the last two decades moving between engineering and security roles at companies like GitHub, Stripe, and Figma, including time as a CSO overseeing compliance for a pharmaceutical company. He joined Workbrew about a month ago, coming most recently from Figma's internal tools team. I sat down with him to talk about why he made the jump, what he's building, and what's surprised him most about life at Workbrew.

Why did you join Workbrew? What made you leave Figma?#

At Figma, I was the third person on the internal tools team, and for a long time, the only internal tools team at the company, since everyone else was focused on the product. By the time I left, that team had matured a lot: we'd grown to seven or eight people, and the scope had narrowed to admin tooling and front-end work. It felt like a natural stopping point as the group didn't need me in the same way anymore.

Alongside that, I've spent about 20 years moving in and out of security and security engineering. I care a lot about regulatory compliance, but specifically about making it survivable for the humans involved. Compliance is often painful, either the people doing the auditing are stuck doing manual work in Excel, or the experience for developers is awful.

At places like Figma, Stripe, and GitHub, I saw firsthand how painfully some of these problems get solved. Every new piece of software needs approval from scratch, even if other people are already using it and the company's fine with it. Sometimes that's for good reason, but it means people end up stuck running four-year-old tools because they can't face the approval process again.

In an earlier role as a CSO, we cobbled together programs across roughly 20 different partners to do what Workbrew does in one place. This was at a pharmaceutical company, so we had HIPAA requirements on top of standard tools like Jamf, plus a whole cordoned-off, Chromebook-only environment for support teams who couldn't even keep local files. Juggling that many compliance needs across that many tools is genuinely painful.

What Workbrew is trying to fix is that balance: you can set whatever policy you want, and it only gets in the way as much as it needs to. One of the core flows is just requesting a package. You're not sent off to a third-party system like ServiceNow or a JIRA ticket where the request disappears into a black hole. It happens in the same place you already manage your software, and whatever evaluation your company wants to do still happens behind the scenes.

That matters to me because I still think the ideal developer environment is taking your laptop, turning off the internet, going to work in a park for an afternoon and knowing everything's secure. A lot of companies solve this by moving development entirely into the cloud. Workbrew's approach genuinely supports local development instead, with on-device checks that help ensure nothing shady is happening with software installs. I like what we're trying to improve here, because it's a problem that clearly needs solving, and we're in a good position to do it.

What perspective do you bring from your CSO experience?#

For earlier and mature organizations, you need the same underlying assurances auditing and compliance requirements, scaled to fit the current footprint of your company. I have expertise in both the earlier-stage and later-stage practices, so we can bake those expectations into the systems we build now, while keeping great developer environments at the forefront. 

So a lot of my focus is on making these processes smooth and automated as we scale, while keeping an eye on where we're headed. Our level of diligence reflects how much we care about people's data, and right now we are growing from  human-plus-automation flow to a  fully automated approach with human checkpoints. I'm working to help move that forward and just as importantly, make sure it's not knowledge that we all know well and have internalized.

What are you working on right now?#

I started by getting familiar with onboarding and the automations already in place. When it came time to pick a feature, I looked for something that would force me to understand the whole system — which is how I landed on the formula allow list. A few people warned me it was a big feature to start with, but I don't really think in terms of "hard" or "easy". I think in terms of how well I'll know the system once I'm done.

I've been a terminal user exclusively since the 90s, starting on AS/400 and Novell NetWare server management in high school. I like living in text. Requesting packages and managing what's installed is something a lot of people want to do entirely from there, and it needs to evolve quickly but safely. Right now, a lot of the industry's answer is closer to "this is all that's allowed on the machine — uninstall anything else you find," which works fine until something like malware slips into the community. I want to make this experience good and treat it as a primitive that anything we support can use.

This is only the second time in my career, outside of my early days at GitHub, that I'm building something I'm also an active user of. That matters, because you build something better when you actually live inside the workflow you're designing.

What has surprised you about working at Workbrew in your first six weeks?#

I already knew several people here well, some for over 20 years, so I had a good proxy going in for how much they care about things like treating people well, working async, and documenting everything. One thing I try to do at every company: everything important should have a URL. Slack is great, but nobody wants to click a link that takes you 14 months back and hope it's still in retention.

Working with everyone day to day, it's clear people are operating at a high level, just in completely different domains now. What's stood out most is how willing everyone is to meet you where you want to work from. If you like being heads-down and off-grid for a stretch, people will coordinate around that, while still being flexible about when you're actually needed. That's been a new experience for me. I'm on the West Coast, and I think I might be only the second person here based there. Usually I've been on the East Coast bridging time zones with Japan, Europe, and the West Coast. Despite that, there's been real, deliberate effort to keep everyone connected.

The other thing that's been a huge bonus: ownership here isn't siloed. Someone might be the go-to on a given area, but everyone works across areas. My focus might be the formula allow list, but nobody blinks if I want to pick something up in our agent or in onboarding docs. That's the best signal for me that a company is set up the way I want. I don't need to be the expert in everything, I just want to be able to help wherever it's useful, especially at this size, where what each of us does directly moves things forward.

What are you excited about in the next six months?#

First, I want to ship something big and get a real feel for the support cycle that follows: feature flag it, do some user testing, get it into early access, then find and fix the edge cases that inevitably show up. What I like about this work is that fixing those edge cases means real IT and security admins, sometimes whole fleets of them we'll never meet, get a problem removed from their day. I enjoy writing software, but that's not really what drives me; solving painful problems for people is. It's the same thing I love about open source: when you fix something, you fix it for a lot of people at once, sometimes before they've even hit the problem themselves.

Longer term, I want to get more fully into other parts of the product. I manage fairly strong ADHD by keeping two or three projects going in different areas when I can. That way, if I get stuck on one, I can flag where I'm at, pause, and switch rather than stall out. As the surface area here grows, that just means more to learn and get good at.

Last thing: I'm hoping to travel more this year and actually meet more of the team in person. That always speeds everything up.

Is there anything else you wanted to share?#

Getting to introduce folks like the Kentucky Teachers Association to what we do and what we solve has been genuinely exciting.

Some of the setups I've seen, especially at older universities, are painful to watch in practice. Showing them that something better isn't out of reach has been one of the best parts of this so far.

It's rare, in my day-to-day work, for people I know personally to actually use what I build. Usually I'm working on internal tools or something in a narrow corner of a dev environment. Getting to hear people be genuinely excited about a product I'm working on has been a nice change.