A lot of the time we say that “culture comes from the top” and talk about the responsibility of CEOs / executives / managers to set the culture. I think this is super true, but I am not a CEO or manager or anything. I work as a software engineer.

It’s also true though that individual software engineers have some power! So I want to talk about a few positive experiences me and my partner have had making tiny changes at work! It turns out I’ve mostly worked on interviewing / recruiting in engineering.

Here are a few examples of things my partner and I have tried to make a little different at our jobs over the years.

fairer interviews

When I started doing phone interviews (a few years ago now), I wasn’t given any clear standards to evaluate the people I was interviewing. And I didn’t feel like I was doing as good of job as I should be, so I asked some friends for advice! One of my amazing friends suggested that I write down a rubric (a set of clear guidelines to determine whether the candidate passed the interview or not) for myself to use. So I did! I found some other rubrics we were using internally, and wrote “Julia’s phone screen rubric”. I put it in a public document and said other people could use it if they wanted too.

Eventually some colleagues gave me some suggestions about things to add to my rubric, a few people started using it for themselves, and I made some changes. Then one day people decided to standardize how we evaluated phone screens, it got adopted as the standards everyone in engineering was going to use to evaluate phone screens, and a few more changes were made to make it even better.

It turns out that having consistent standards is really cool! There are a ton of different possible things to care about in interviews (do they test their code? How are their debugging skills? Do they write ‘idiomatic’ code? how charismatic is the person?). Having a clear rubric helps make sure that.

I definitely didn’t change this by myself (in particular, somebody else made the decision that all interviewers should use consistent standards, and many many other people contributed) but I think I helped a little bit and that made me happy!

Also I think this is an interesting example of how the best way to make change changes over time – like, today if I wanted to change our interview rubrics I probably wouldn’t just announce “hey, I’m changing how I do it!” because we have an existing process and I think it’s important to respect that. But back then I think that was a totally fine thing to do, because there wasn’t a consistent standard anyway so introducing a new standard didn’t cause any conflict.

building postmortem culture

My partner Kamal started at an (awesome) new job recently, that he really likes. They’re still relatively small, and hadn’t built a habit of regularly writing postmortems for every incident yet. After the first incident he worked on, he wrote a very detailed postmortem about what happened.

A few weeks later, he told me “huh, other people have started regularly writing postmortems for their incidents too! It looks like we have a culture of regularly writing postmortems for incidents now!”.

I thought this was really cool because it’s an example of how doing something yourself once or twice can make it way easier for people to do the same! It’s way easier to write a postmortem for an incident if you have an existing template to work with that your coworker wrote last week.

what to expect in interviews

A few years ago my awesome coworker Kiran and I were talking about how a lot of candidates don’t know what to expect when interviewing at our company. We basically wanted to write down the same tips we’d give to a friend about how to prepare for the interview, except, well, just put them on the website and give them to everyone. There are a lot of basic things that aren’t obvious like:

• Should I bring a computer?
• What should I wear?
• One of the interviews involves the basics of the HTTP protocol so it’s important to be familiar with that!
• We expect people to code on their computer so it’s useful to set up some common project boilerplate in advance
• We really like it when people bring questions to ask their interviewers!

I thought this was important because when I interviewed for jobs last, the interviews and what kind of preparation people expected were often quite different from company to company, and as a candidate (and especially as a candidate who doesn’t already have a friend there!) it can be unnecessarily stressful.

So we wrote up a “what to expect when interviewing” document, someone else made it into a pretty PDF, and we put it on the website!

I just googled (“what to expect stripe”) and found out that today we publish 6 different “what to expect” documents for different jobs, and that there have been a lot of changes to the original document to improve it / keep it up to date as our interview process has changed. So cool!!

a more welcoming job description

A bunch of our job descriptions got revamped recently. One thing I sometimes see in job descriptions is “you should have experience in $EXACT_THING_YOU_WILL_BE_DOING”. I always find that frustrating because, well – lots of the best people I know didn’t have any experience with the specific technologies we work with before they started here (including me!) so why should it be a requirement?

So I was like “I know! I will write a job description that I think is a fair description of what we need!”. I wrote a job description for the job I have. In particular I added a new “Projects you could work on” section with specific examples of projects so that people could see what they might actually work on. And then I got the appropriate people to review it, we made some changes, and it got posted! This was a pretty small thing but I think it is a good job description.

And last week a manager on another team asked me for advice about how to make their job description more clear about what the job is and sound more inclusive and I told them what I thought!

For this one my manager at the time helped me a lot – I said “hey, I want to write a job description for our org”, and he told me “awesome, here’s who I you need to talk to to get that done!” and gave me some useful advice. It didn’t matter that I’m not a manager or team lead or anything which I thought was cool.

better documentation

Until recently my team didn’t have that much documentation for the infrastructure / tooling we maintain. There were a lot of things that lots of people knew, and that if you asked someone they would definitely explain to you, but just weren’t… written down anywhere. I made it one of my personal goals this quarter to improve our documentation a lot. So I’ve written a bunch of documentation myself, sometimes I’ll pair with someone to document a system that needs it, and other people have been writing new docs too. I’m excited about it and I think it’s easier for a new person to come in and start reading to learn how our systems work than it was 6 months ago.

As an example of something that didn’t work that well: when I joined, I wanted to make our documentation better, but I think I tried to make changes / ask people to make changes kind of all over the place and it was too scattered. Doing it in a more focused way (“I’m just going to document stuff on my team”) has been a lot better.

some changes are too big, though!

I spent some time last year advocating for us having concrete goals around making the engineering team more diverse. We did end up setting some goals, but I don’t know whether I made a difference at all – some things really do need someone higher up to decide them. (I actually think the approach they came up with is pretty cool, but it is not my thing to write about here)

So while there are lots of changes you can make by leading by example and from the bottom up, this approach definitely doesn’t work for everything.

you can make changes, maybe

Not all of the changes I’ve tried have worked (and I’ve left out the things that haven’t worked :)), so this is a pretty optimistic view. But I really do think that software engineers at tech companies sometimes have a bunch of influence, and if I do the work to help make the change happen, sometimes things can be a little bit different! I see a lot of other individual software engineers making changes to make things on their teams a little better and I think it’s awesome. All companies are a work in progress and things cannot be good unless we make them that way together :)

Some things that have helped me:

• Work on one thing at a time. I have a regular engineering job to do, so I only do one “side project” like this at once. So if I’m working on organizing an event, I’m not allowed to write a job description.
• Doing the work myself to start is easier than asking somebody else to change how they’re doing something.
• Trying small changes first. Even if what I want is for all of our interviews to have standard evaluation guidelines (today that’s true!!), I can’t make that happen all at once, it’s easier to say “ok, I’m just going to make some guidelines for myself to use”.
• Work with other people!
• Remember my coworkers are probably on the same side as me :)

Some other examples of making this kind of change:

• Sumana Harihareswara’s great post Implementing the Friendly Space Policy for Wikimedia Foundation technical events