I'm here today to talk about company culture, performance reviews, and you. We might as well kick it off. I've already been introduced. But I'm a site reliability engineering manager at a company called Splunk and and I work on our cloud project. I've been a sys admin for nine years, so if you have questions, I'm unfortunately the person to ask. I've been a manager for about a year, so I do know what it is like to be an individual contributor, or IC, as they're known in managerland.
This was written from the perspective of an engineer before I game a became a manager. I've just finished - there's going to be a running theme here. If you're a Star Trek fan, I'm sorry you're not going to get these analogies. You might be wondering why I have two pictures of Yoda on the screen, or for real fans, a baby of the Yoda species, and Yoda himself.
That's because basically in this talk, I want to take you from the child essentially, lost and confused in the galaxy to Yoda who I'm sure Star Trek fans can agree knows what is up. This is what we are going to cover today. It looks kind of dry, so instead of reading every point on this slide, what I want to talk to you about is an experience I had that's the reason I decided to write and give this talk, basically.
So I was going to say company A and company B, but it's spoilered by saying the companies I worked for. I'm going to say nice things, so I will use their actual names. I started like any new sys admin careers at Rackspace. I was there for five years, and I had a great time. It was a really good experiment for me. I progressed a lot. I was promoted a couple of times, and one of the things I was conscious to do while I was there was take on the feedback I was given by my managers specifically in my performance reviews. I really spent a lot of time thinking about that feedback and working on the things that they suggested I should.
Cut to two years ago, I decided to switch careers, and I came in as a senior site reliability engineer at Splunk, and I was having a great couple of months starting off, and then it came to performance-review time. Splunk does things a little bit differently. They also ask your peers and random people you may have spoken to in the business for feedback and then give all of that to you.
I was nervous going into the performance review but I knew what I was going to get, what I should get from my old job, and what I was good at in my old job, and a little bit of a shock because my manager sat me down and started to list things, and he said these are the best things that you do. We're so glad you're here. What strength, wow. Amazing. And you could imagine that that was a little bit disconcerting for me. I was pretty sure I was being punked. But what it did do is make me go away and think that doesn't make any sense. How can something in one job be pitched as a weakness or hindrance and, in the other job, suddenly, it's a massive benefit?
So I spent the last year thinking about that as a manager, and as a manager, I can tell you, there's no easy answer to any of these questions. I can give you, though, a broad set of assumptions we can make about different companies and then how you can career-plan around that to get the most out of it and do real well in your performance reviews.
The dictionary defines culture as the ideas, customs, and behaviours of a particular people or society. In tech, we love to talk about culture. We want to talk about drinks after work, we want to talk about how my office has scooters, and a slide. And we also really like to talk about it as a way to keep anyone who is not a white cis man out of our teams. When I'm not - I'm not talking about that culture, but business culture. That's how the culture of the whole organisation permeates a team and impacts performance review feedbacks and your career opportunities.
Sometimes, it's easier to talk about what something isn't to give you a better idea, so that is what I'm going to do now. Everything on this list, it's not company culture, it's a compensation package. These don't indicate anything about company culture. Your company provides these to you in order to provide a competitive package to attract employees. It's on top of instead of salary or stock compensation. These perks are also thinly veiled ways to ensure you spend more time at work, and, if not that, the time you do spend is mainly spent at your desk, so not culture. Baseline humanity, should not have to list these. That's not culture. That's what I expect as a human from you. [Laughter].
So, what is culture, then? Well, it's about risk. For those of you who are young and don't understand this, this is the Death Star. [Laughter]. What are we willing to gamble in order to get our big payday or Death Star explosion? If you've not seen Star Wars, it was a very risky move. Culture is about risk, right? Risk is the exposure of something to danger, harm, or loss.
We are also trading off risk with what can we gain if we take that risk? That means there are two ways when you generally think about risk. You say what could I lose, and what could I gain? It turns out that they've done studies on this, and humans have something called a cognitive bias, that's been named "risk aversion" which basically means we will always choose not to lose what we have over any potential gain. We will always be more prone to preserving what we already have.
Tl;dr, your brain hates losing. As someone who has been banned from a lot of family monopoly games, I can confirm that! What does this have to do with business, then? What else? Money. All business decisions involve revolve around risk, and risk for a business, and let me be clear, I'm talking about capitalist business here, so - so, for a business, most are explicitly capitalist, so the number-one rule they have is to make money. That means the thing they don't want to expose to risk is money.
So we can basically boil a company's culture all the way down to risk management. How much risk are they willing to take on? How much money are they willing to potentially lose in order to achieve their business goals? Once we kind of understand that, and we also know the human bias, for loss aversion, you can extrapolate that the larger and more successful a company becomes the more risk averse they will be. They have more to lose, more money, and, often, if they're IPOed, they have to report to shareholders on top of that.
If you're a younger company, maybe a start-up with a bunch of seed money, you'll be more willing to take on a lot of risk because what is funding if not just fancy gambling? Much like the Force, there must always be a balance. If we don't want to have risk, how can we mitigate that risk? How can we reduce it? It's achieved through the introduction of everyone's most hasted word, "process".
Process here I'm using here generally. I'm just referring to anything that provides a way of creating repeatability and expected outcomes. So, that can range from anything from a runbook for how to make a change. It might be automation that mean the same result always happens, there are or it might be something like your onboarding documentation, or a structure around how you do hiring or reviews. It essentially means we risk less because we know exactly what the outcomes should be.
Now, from a personal engineering level, you can begin to see that this generally provides us two very environments or cultures. That's because there are two many ways that engineering teams reduce risk. One is reducing impact to affect large areas, you may have heard this as "blast radius" and the other is providing documentation and training to their engineers.
This minimises human error - bad - but also means happy employees which means they don't leave and they don't have to spend all that money of getting someone from 0 to 100. So what will that look like for you? How can you think about companies in that way to benefit your career growth? Well, we're staying with the star warms theme.
We're going to start talking about high risk, right? This usually takes the form of maybe a start-up or a small product team in a larger company focusing on a brand new area, right? These are risk-heavy teams. They're Hans Solo and Chewy. Who shot first? Doesn't matter, he's dead. Like we said here, there are always downsides. You might do really well. You might end up famous for your - but, in this kind of an organisation, a engineer can make a big impact fast. However, they will generally spend a lot of time not really knowing what is going on. The organisation could panic-react to events a lot and there is a lot of change. There is almost always going to be a large degree of ambiguity and let's see what happens.
So, this is also, I would like to add, where you're most likely to personally break construction in some catastrophic manner. So this kind of environment is great for someone who might be already pretty confident in their technical skills, or, if you're at the start of your career, you might be the kind of person who just loves to throw them in the deep end. If you were that kid in swim class who dove off the highest board? No, that wasn't me, I was on the second step, crying! It also generally means there's a lot less support and documentation and you have to figure things out as you go, and, if you're someone able to to help mentor or produce this documentation, you would do pretty well in this company.
What is the opposite side? It's the Jedi. These are risk-averse cultures. They normal take the form of more mature organisations so we can think like Dell, perhaps. So these guys had years of established wisdom, and that results in lots of training and mentorship. You usually get to learn and experiment in a really secure environment. They generally have good tests, and you can't just push stuff to prod that will break it, and they're often built to teach you to grow engineers. Usually, that also means that you get to do things that have a pretty large scope because they generally have a big large infrastructure, so that can give you a little bit of a foot up into thinking about broader architectural issues.
The downside that the Jedi are slow to adapt, and they have a lot of meetings. All of those cancelled scenes that are in Star Wars? You understand, right? So they are a good place how to make large changes at scale, but you need to gain a lot of group consensus to do it, and you have to go through a long period where you're earning that influence, essentially. So, these can be great companies to start out a career in a strong learning environment, somewhere that you feel safe that, if you make an error, a test fails, and someone's going to come and say, "Your test failed". All of the phones if the company are going to suddenly start ringing. It can be a good place to come to at a senior level and you want to start working on skill sets that involve more areas of getting buy-in from other people.
How do I influence other people to come round to my pattern of thinking? Those sound like extreme signs. And you probably aren't going to end up in one or the other realistically been most companies and most of us end up like Princess Leia. For the most part, we will kind of oscillate between these two polls, right? The companies at the end to grow in one direction while we as engineers and back and forth depending how our skill sets develop.
For the most part, we will work in the culture our strengths are in when they align. I'm not talking about technical strength, not about, cool, I'm a Kubernetes engineer, or I write really good PHP, in fact, I'm talking about things like a broader set of skills, so I'm really good at writing clear documentation, or I'm a fantastic teacher, and people really tend to understand things when I've explained them to them.
Some of us are built to be Yoda, and some of us want to blow stuff up, and some of us don't care. There's one caveat to this, which is culture sits at many layers. So a company can be mature and really risk-averse and still have smaller teams that are accepting of a lot more risk. That's normally a green-field project or a company that's decided to buy a small start-up, and that's our new product. You do need to consider all these aspects when generalising company culture, but one thing that is true is that if you're in a mature company but in a highly risky team, they're going to be able to become mature at a much faster rate than a start-up normally will because they just go to the main parent company and take although process. They don't have to work it out. It will generally become more mature faster than a start-up.
I said this was going to be about performance reviews, and I promise it is. If you take one thing away from today, what I would like you to take from this talk is that performance has nothing to do with how smart you are or how good an engineer you are. Performance reviews are about how effectively your strengths assist the business in achieving its goals.
A high performer is an individual whose strengths align with the team. There is always growth in feedback. You should listen to it but understand that the feedback will be situationally specific. While you should listen to it and take it on board, remember to contextualise it in the larger culture of the team and the business.
So, at the beginning this, I said I had had a personal example. It really is personal. These are three pieces of feedback that were delivered to me. I want to be clear that this feedback was not wrong at either time. It reflected my performance in the context of the company that I was working in. So, there are some things that you can probably guess in this feedback, and also by what I've been saying in this talk, which is essentially that I'm pretty good at work out in efficiency.
It's one of the things I - working out inefficiency. Whether in a engineering or process context, I want to fix it yesterday. I also - I'm not shy to give my opinions. I will pretty much say, "This is how we should do it?" Another thing I'm pretty good at and that I like doing is writing technical documentation. I like documenting a process, or basically building a path for the person coming behind me to follow along. So, what I'm going to do is discuss just a little bit how this feedback essentially was given to me.
So, at my first job, Rackspace, it was a much more mature company, right? When I would turn up, and I would see a process that I thought was ineffective, or frankly dumb, I would turn around, and I would say, "This sucks. Let's change it - now." That wasn't great because there was a lot of context behind engineering decisions that happened there. There were a lot of people involved, a lot of different teams that relied on a lot of those systems and having someone turn up and want to flip it and change how we did it, it wasn't necessarily great for a risk-averse business that didn't like to take too many risks. So that was some feedback I was given, hey, work on this. Big larger consensus. You don't need to change every finally single thing that's wrong right now.
Similarly, it was a really mature company, so my desire to write a lot of documentation, to write War and Peace in my Jura updates that was seen by my managers as a waste of time. We have documentation for it, so just write, "I fixed the problem", you don't need to write 20 lines about how you fixed it. So, you can see how in a more Jedi-like organisation, these strengths just didn't quite align with what they were looking for.
When I moved to Splunk, we were a much younger organisation. Splunk is quite a mature company, but the cloud department at the time was a little bit less mature in our processes, so turning up and saying, "Hey, I see this thing we have isn't great, can I try something?" They would just say yes, because a lot of the time the context for why that decision had been made was usually fastest, or, "I just had done it before that way."
So that suddenly became this real strength. I was turning up, and I was fixing problems as they popped up. And because we were more happy to have risk, it was fine if I wanted to try something, and, if it went wrong, I would revert it, not a big deal. Similarly, we were a young company, we didn't have much context. Pretty much everything I did in the first six months I had never done before and I could never find any evidence of anyone else ever having done before.
So my own leaning to documenting things was suddenly this huge strength where people were saying it's great that you wrote 37 wiki pages this week. That was a really useful time sink for you, essentially. Now we're lucky we have technical writers for that, so they've taken them and made them neat and taken out my funny references, sadly!
So here is the thing. That culture that I just described at Splunk, well, it shifted so much from when I started. We're now becoming more and more risk averse, which is great because we are successful. We have customers who would be upset. So does that mean it's time for me to get a new job because all my strengths are useless? No. There is, in fact, plenty of scope still for us to bring in new process, for us to improve efficiencies, and one of the cool things is I can now leverage a lot of that process I learned at a more mature organisation and take the bits that worked, and I can a I apply them and seem like a hero.
So, I've now found the strength that I want to develop and focus on, and I think and I know they're particularly beneficial to a business that somewhere in the middle coming from start-up into maturity, and doesn't really know how to do that. So I can kind of understand that. Thing that you need to do is keep an eye on your strengths, how they are changing, anything you might want to grow into, and also because companies change and a job that you love today and is an amazing role for you, in six to 12 months' time might just not be the right fit. That being said, how do we work this system? Well, check-ins. I have had a couple of worrying conversations that imply people are not getting regular performance reviews. Yell at your managers.
If your manager is not giving you a performance review, you should be giving yourself a performance review. Self-evaluation. Keep your brag document. Go through it. Check you're on par. Instead of having technical skills in there, put in other strengths like turns out I'm really good at getting through a change-approval board, or I've been mentoring, and it's been going really well, and I enjoy that. Periodically evaluate your own growth. Crowd-source. Speak to your colleagues. Speak to your manager.
Speak to managers of other teams, colleagues on adjacent teams, and assess whether that they think that cultural alignment is, does it match what they're actually doing? Because a lot of the time, it's not going to. If they say, "We're very risk-averse, we don't want to break anything but no-one has to review your PRs to put them into production?" I would question that. Just gently gently think about the strengths you would like to - generally think about the strengths you would like to foster and how useful it will be to the business and make sure these overlap to hyper speed your career growth.
How to assess - it's all well and good I tell you to assess it but not how. These are questions that are really useful. The answers to these questions will help you judge how much process and documentation exists around the engineering work you're doing day-to-day. This can help you risk averse your team is, not just for code you're writing, but goes for things like, "If we hire a new person, do I know what to do with them on the first day? Do I know what to do with them two weeks down the line?"
Again all of this will tell you where your company is going to eventually because everyone marches towards maturity and process will need to put these into place and where your strength can align with this. SLOs are a really nice one because they are a literal percentage of how much the company cares about downtime. We asked our questions. We got our answers. How do we actually leverage this to our benefit? How do we form a plan? If your preferences and strengths seem like they're a good fit for the current culture, that's great. Start working with your manager to find out where they can have the most impact.
I'm going to break out a little bit from our Star Wars analogies for the next slide. Basically, I said talk to your managers. If your manager is not useful, talk to another manager. Hopefully, he knows a bit about your team. Why have I told you not to just find a senior engineer or different mentor? That's because I think that there is a very specific thing about a manager who manages on your team, or near to your team, that they can offer you, and should be offering you. I'm going to break away from Star Wars and go to my number one obsession, women's football.
I know this is not necessarily a sports audience, so I will be very clear. This is Julie Ertz who is a centre-back defender on the US National Women's team. In 2015 when they won the World Cup for the first of two back-to-back tiles, she played every single minute as a defensive centre back, right? She goes back to Chicago, her local team, and she continues to play centre back. The back line there under her mentorship becomes really, really strong, but what happens in 2016 is that we realise our midfield - that's the middle of the pitch - is really lacking.
We have good players, but honestly, they're tiny, shorter than me, and they get bumped off the ball. It it's distressing to watch. Our coach says let's take Julie, who you can't see to scale here, but the woman is big, like you would run away if she was running towards you, and he says, "You're going to attacking midfield." You don't need to know much about sports, but defender and attacker, not the same. The reason this is important is because basically that's a decision that only a coach can make. The coach understands that the midfield is where the business/football team needs to focus, and he's taken the strengths that he sees in an individual and moved them into that position.
Now, it turns out she did great there because what we needed was a little bit of brute force, and she absolutely brought that. In the 2019 Olympics, she once again played almost every minute, but, in fact, most of that was in an attacking midfield role and sometimes dropping back into defence. That entire story is basically about how if you and your coach and manager are aligned, you can work out how to make yourself indispensable, right? A good centre-back is always going to be decent, but one who can switch to attack and then drop back when they need to, that was a great example of aligning a player's development with what the team did, and there we can see how that shoots your career up to the next level, essentially.
So, use your manager. Another engineer is not going to be seeing the bigger picture of who they're going to draft next season and what their opponent's weaknesses are. It sits with your manager to be able to give you that perspective. Perfect.
The takeaway from this is there is no wrong place. I don't want anyone to feel like I'm in the wrong place for the wrong stage of my career. These are merely areas that can help you focus on different strengths and skill sets. Ideally, you want to be in a place where what you view as your strengths is the same thing as what your boss and team-mates view as your strengths. Know what areas you're strong in, or areas you might like to grow into, and think about the company culture, and kind of use a bit of a yardstick to guess that I've given you from this, and, when you find that you can align the strengths of what you bring to a business, and what the business needs from you, and from engineers, then you will find yourself getting consistently strong performance reviews, and plenty of opportunities to advance.
That's my talk. Thank you. You can find me at all of these places, and we are always hiring. [Applause].