Bill Weiss - fmr Sr. Staff Security Engineer at Airtable

Bill Weiss: personal site, Twitter

Tell us a little about your current role: where do you work, your title and generally the sort of work you and your team do.

Up until recently I was a staff/senior staff security engineer at Airtable, working on the Infrastructure Security team. I was the first person on that team and helped build it out into a few people and a manager. We were responsible for securing the platform that the Airtable services ran on, which included everything “below” the running application, such as AWS accounts configuration or EC2 instance builds.

How do you spend your time day-to-day?

Airtable doesn’t really have “normal” Staff folks :) I think I was the only Staff+ in the security org. Like most people in these roles it varied week to week.

• Meetings, of course, about half of which were team ceremonies for either the Infrastructure Security or Production Engineering teams.

• Pairing on projects, where we’d be writing code or working on documents.

• Solo document work, either writing my own, drafting for my management, or reviewing for other folks. Lots and lots of standards, procedures, and RFCs floating around as well as doing review for engineering team RFCs.

• Writing code, mostly Terraform but some Python.

• Research! Airtable’s security org really values research and made time for it, so we were frequently trying new things, looking at clever hacks we read about, etc.

Despite coming up on my fourth Staff+ role, I’ve never really been promoted into the position. I was on the manager track for a while and twice now have sidestepped from a senior manager position into a Staff+ role. The first time was at Puppet after we split my team into two and I promoted two ICs into management positions. After a bit it was clear that they didn’t need me between them and my boss, I was interested in getting hands on as an engineer again, and there was an opening for a high-level security engineer, so across I went. I tried my hand at management again at Rally Health for a couple of years before realizing I really enjoyed the IC life more and, again, there was an opportunity to move sideways into a Staff+ role.

I feel super lucky that I’ve been at a couple of companies that really believed in IC and Manager tracks being side by side.

What two or three factors were most important in you reaching Staff? How have the companies you joined, your location, or your education impacted your path?

So much of it has been the company and my managers. Without the company buying into the parallel IC/manager tracks, or the managers valuing my growth over the position I was in, it would have been really hard to make the move. When I made the first transition at Puppet I had been a full-time manager for a few years and felt pretty rusty on my technical skills. They helped me see where I could be effective right away (there’s a lot more to the Staff+ role than code, who knew?) and how I could ramp up.

I’d honestly say that my education hasn’t been very important in my growth. I have a degree in Computer Science, and maybe I underestimate how much that background helps, but I don’t see myself doing much of what I learned in school at work.

Some of Bill’s Public Work

• Everything is Terrible: Three Perspectives on Building, Configuring, and Securing Software

• Talking to lawyers (without catching a case)

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

I think my sweet spot is helping a project go from proof of concept to finished. I love coming up with new ideas (who doesn’t?) but there’s something to be said for just getting the last fiddly bits done and out the door. Turning off that old system, finally deleting some code that isn’t called anymore, that’s what I love. It’s handy that in my career I’ve been able to come in at that point and grind through the last steps of a long project. It’s also a place where there’s frequently a lot of cross-team work to track down those last bits that were left for later.

When I moved in to supporting the Rally Health ops team, they had run a big project to move AWS access out of individual IAM users and into SAML-assumed roles. The project had gone super well and it was clearly the way forward but the team had lost some of the momentum to go through every last user and make sure they were migrated. Each of them had to be checked on, made sure they had the appropriate access via SAML, checked for saved credentials (in the early days, people would generate an access key and use it for something automated), disabled, and finally removed from Terraform. Terraform removing users isn’t super clean because of some fiddly bits about order. Even better, all of that had to happen across several AWS accounts, some of which were used differently and thus we couldn’t rely on a change in one account being safe meaning that it was safe in another. Sounds great, right? I saw a place where I could make some happy devs, reduce the toil of maintaining two systems, and knock a project off the books into DONE.

I don’t think there was any magic to how I completed it. I looked at the list of entries in Terraform, compared it to what was in IAM, and just started tracking things down. With repetition I found some opportunities to make it faster, write bits of code to take care of the common tasks, and saw patterns that let me batch parts of it up. It was weeks of work (with lots of downtime waiting for people to test things) but I was getting some nice big red diffs into Github PRs. Finishing it was super satisfying, the ops team was happy that it reduced their work, and security was happy that I had removed a place we had to track and monitor users. It also won some points for the security team in that this wasn’t an unfunded mandate for ops, it was something we came and helped them achieve, and that paid dividends for the rest of the time I was there.

Can you think of anything you’ve done as a Staff-plus engineer that you weren’t able to or wouldn’t have done before reaching that title?

It’s hard for me to say because of my back and forth between IC and manager tracks. Certainly I’ve got a lot of flexibility to choose my own work that I don’t think I had last time I was an IC. I come with some position authority because of the title, and that makes it easier to make cross-functional efforts get moving and continue to move. I also think that it’s somewhat safer to gamble on bigger things as you move up in the org as there’s understanding that not everything pans out. We have to make it safe for everyone to make mistakes, but I think the higher up folks are given more leeway to make bigger ones.

What Staff Engineer archetype do you consider yourself? Why?

At Rally Health I was mostly in Solver mode, taking on projects that required domain knowledge and attention without a whole team. At Airtable it was more like an Architect role, helping guide our early-stage cloud security program. If that team had had more people when I started, I suspect I would have been more in a Team Lead sort of role, but I was pretty emphatic that I didn’t want to be the people leader of that team as we built it out, and it wasn’t big enough that it needed both.