Steve Weis - Senior Staff Software Engineer at Databricks

Steve Weis: personal site, Twitter, LinkedIn

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.

I am a Senior Staff software engineer working on the Trust & Safety Engineering team at Databricks. Our team is responsible for security, privacy, and data governance within the engineering organization. We also partner closely with a separate security organization.

My work varies greatly. I may work on writing code, incident response, design & architecture, design reviews, talking to customers, setting organizational priorities, mentoring, and recruiting. I work closely with our engineering management and leadership.

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

Any given day I may be writing code 10-20% of the time, designing systems or writing documents 20-30% of the time, in meetings or interviews 20-40% of the time, and dealing with one-off or unexpected events 10-50% of the time.

This varies largely over different projects or times. I may get pulled into something that requires a lot of hands-on work for a bit, then end up spending a lot of time on planning and organization work. I think the one constant is adaptability to whatever new problem we are facing.

Can you talk a little about the process for finding your current role? You’d been consulting for a couple years at that point - what about this role drew you back in-house?

I was working as a freelance security consultant with several companies. One of those included Databricks. I had to put that consulting work on hold during the COVID pandemic because of child care closures and was a full-time, stay-at-home parent for several months. Once things reopened, I decided to apply for a full-time role just to get back to having more consistency.

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?

I think a few things helped:

1. Areas of domain expertise. I studied cryptography in grad school and having some area where you can be the company expert helps. But it’s not sufficient for Staff unless there is enough work in that specific area.

2. Experience on impactful, large scale, long-term projects. I had experience driving a large scale project with lots of collaboration and stakeholders over a long period. Part of being Staff level is being able to navigate and work within a large organization.

3. Entrepreneurial experience. I started a company and that experience jumped me several levels when returning to a big company.

Some of Steve’s Public Work

• Threat Model Worksheet

• Building Better Systems Podcast: Security Shouldn’t Be the Last Check Box

• USENIX Enigma 2018 - Emerging Cryptography

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

The times where it feels most impactful are when you ship something that makes a measurable difference, in whatever metric you care about. I also like when you see an organization logjam where people are in endless meetings about something, and can unjam it in a few minutes by answering a question or making a quick change. This often comes down to being the person in the room who can find answers in the code base, who can pull relevant data, or knows who is the right person to talk to. That’s something that distinguishes a Staff+ Engineer from Management: we know where the bodies are buried.

What Staff Engineer archetype do you consider yourself? Why?

I’ve been all of the above, depending on the scenario.

• I’ve been a Tech Lead / PM role focused on delivering a specific project. This often involves breaking down tasks, delegating them, tracking progress, and seeing barriers ahead.

• I’ve been in an Architect role where I was designing a solution that others would deliver. This has generally been thinking ahead multiple quarters or years of where a product or infrastructure should be heading and writing out why and how we should try to get there.

• I’ve come in as a Solver and solo-fixed a critical problem. This might happen in a security incident where I happened to the person around at the time, or where there is some domain-specific question where I had the right expertise.

• I’ve also been a Right Hand, where I worked closely with management on shaping the organization. This involves a lot of recruiting, interviewing, mentoring, and advocating for people internally. Being an engineer can bring more credibility when advocating for someone to get hired or promoted than someone solely in management.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

I have, but I don’t want to do it in a large organization because of the amount of time spent on internal overhead.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role? We’d love to hear a story.

Mentoring is absolutely an important aspect of the role. My experience has largely been in helping replace myself and helping someone ramp up so that they can take over some aspect of what I’ve been doing.

I’ve had the most success delegating when playing more of a Tech Lead / PM role. You naturally need to break out work that multiple people can work on at the same time. This aligns with mentoring someone so that they can own an area or component.

There might be a project that is initially a big Staff+ Engineer level, that when completed leaves some ongoing projects that are good for junior folks to take over and own. They get experience building the whole project on the way and end up being experts in whatever component they end up owning.

What about advice for someone who has just started as a Staff-plus engineer?

The best thing I learned over time was to try to understand other people’s goals and motivations, and how they align with my own. It helped navigate large organizations better and to be able to influence changes.

Also, continually try to improve on written and verbal communication, and presenting visual information. Writing a one page document and reducing a complex problem to a clear decision can be more useful than any code you will write.