Transcript
Nicky Wrightson: We're going to introduce ourselves, where we are, and give a little bit of a descriptor of the kind of culture that we thrive in. For example, I will say, "I'm Nicky. VP of Engineering at Climate Tech, called BeZero Carbon, where we literally plan to change the world. Where I thrive is in a place where I'm able to change the environment that I'm in, and I can empower the engineers and provide autonomy".
Suhail Patel: My name is Suhail. I am a Principal Engineer at Monzo, based in the UK, in London. The environment that I thrive in is one that ships really frequently at high velocity, and also an environment that has a lot of psychological safety in the company culture.
Lesley Cordero: My name is Lesley Cordero. I'm a Staff Engineer at The New York Times. The cultures that I like to thrive in are definitely ones that are psychologically safe, like Suhail mentioned, but also ones that drive forward a culture of excellence, very much into reliability management and quality. Those are the kinds of environments I love to thrive in.
Matthew Card: I'm Matthew Card. I'm an Engineering Manager at the BBC, which maps to like a Head of Software Engineering, or a Mini Head of Software Engineering. What cultures do I thrive in? I thrive in an understanding culture. For me, my line manager, or the environment has a very big impact on my success at work. It has to be a culture that understands people.
Natan Žabkar Nordberg: My name is Natan Žabkar Nordberg. I work at a fintech called topi. I'm also an Engineering Manager. I thrive in a culture that sees people for people instead of numbers, and that is, let's call it diverse and inclusive of different opinions, of different experiences, and of different approaches.
Approaches to Shaping Culture
Nicky Wrightson: We often say that building culture isn't just leadership responsibility. It's something that everybody contributes. I imagine that many of the engineers will be interested to hear your story and how they can influence in a similar manner. Could you share some of the approaches you've used to shape culture throughout your career, maybe early on in your career and now later on?
Cordero: One of the themes of my talk was about feedback loops and how that can be input for improving our culture, because it allows us to find early indicators of dysfunction and whatnot. I think as a junior engineer, it's super crucial for you to utilize those feedback loops. Hopefully, there's multiple avenues for feedback loops.
The most common is engagement surveys and one-on-ones with your managers or whatnot. I think it's particularly important for junior engineers to utilize those because as you go up the ladder, you have more access to people and leaders. That's not as true when you're a junior engineer. That's definitely one of the ways that as a junior engineer, I was able to give feedback in that way. I think the other strategy that worked really well for me was finding good allies and sponsors who would listen to my feedback and evangelize that for me, especially because they have probably more social capital. Also, tenured people tend to be good allies because they know the company culture more. Those are definitely some of the strategies that I've used. As I've grown to be a staff engineer, I also try to do that for others. That's also something I would encourage our senior ICs to do.
Lending out Social Capital
Nicky Wrightson: Matthew, I saw you nodding away at social capital there. I wondered, do you lend out your social capital? Because I expect that you've probably got quite a lot being at that level of management at the BBC.
Matthew Card: Yes, I do, a lot. I rather talk to people than actually do my work, because I like to empower people. I briefly spoke about it in my talk, is there's different types of energy. I think that exposing people is a type of energy where I'm giving my energy to somebody else so they can then grow, they can then understand the situations that I'm dealing with. They can think, how would I deal with it? He's done it, I wouldn't do it that way, because I'm ok for people not to agree with me. I would one-up you on your feedback loops. I like to say feedback conduits because I want to make sure that it's going both ways as well.
Tech as a Performance Driver
Nicky Wrightson: Suhail, you are renowned, or I know you from extensively talking about platform engineering. Monzo's very well known for their continuous delivery, microservices, and the platform engineering that goes into that. Is it the love of the tech or the culture that you thrive in that you described earlier that's driving it, or are the two indistinguishable?
Suhail Patel: Technology drives performance. Technology is the thing that we're shipping at the end of the day. That's the thing that we get measured on. Often, in our organizations, we talk about impact. It's quite fascinating still to this day, despite all of our protestations, we still measure people. An input to measuring people is the amount of PRs they've shipped or features they've shipped, or the things they've been involved in and the projects they've been involved in, despite those things being not really good measurable indicators.
In thriving technical organizations, a part of what I talked about in my talk is organizational cracks. There are things that happen that are within the engineering realm, things like onboarding and hiring and interview practices and things that are just fundamentally broken within organizations. As engineers, as ICs, we contribute to the dysfunction, especially as we climb towards the ladder. These are things that we can fundamentally challenge. It took an engineer at Monzo to ask, why do we have a task where we put engineers under pressure? Why do we put them under this kind of pressure? Why don't we just give our interview process away? There are all of these kinds of dysfunction where we can challenge the status quo, and I think that contributes to the culture that we have internally, which is really transparent, proliferating externally to be equally transparent to people on the outside.
Organizational Culture vs. Engineering Culture
Nicky Wrightson: Do you think there's a fundamental difference in terms of organizational culture and engineering culture? Because you talk about shipping fast and you talk about some of the interview side of things. Are we looking for engineering culture or is engineering culture actually just a by-product of company culture?
Suhail Patel: I think it could be both ways around. For example, our engineering culture has proliferated into the rest of organizational culture. We work as a bank. Banks are meant to be very boring, but banks are also being known as being very risk-averse. I speak to many of our teams, many of my counterparts in areas like risk and compliance and legal and a lot of other areas, which fundamentally are meant to be risk-averse.
You look at your second line and your third lines, they need to have a full understanding of technology and a full understanding of how we ship on a day-to-day basis to challenge their own internal status quo to understand that our ways of working are not completely incompatible. We don't need to ship on this major cadence. We can ship these small artifacts. What we've been able to reflect in our engineering culture, we've been able to proliferate in our writing style, not writing with a lot of jargon, making things as simple as possible, abstracting things away, adopting new tools. We've been able to empower other parts of the organization and influence on organizational culture. Conversely, in engineering, often we think about folks who, again, I'm going to use risk and compliance and legal, these things as like bougie people, like people that we hardly interface with or just here to slow us down. Whereas you look at a lot of the things that they deal with, a lot of interpretation of regulation.
One of the things that we often talk about internally is the spirit of the regulation. What is the regulation aiming to empower rather than the actual word of it? The word of it, if you interpret word by word, will lead your engineering culture into a complete array of dysfunction, will slow you down absolutely massively. When you try to work with these folks and trying to understand the spirit of the regulation, what it's trying to empower, it wants what you want in engineering with reliability and stability. The two are in common. That's what they want from a risk and a compliance point of view as well, is reliability and stability. Helping people understand on both sides of the equation can lead to both organizational culture and engineering culture matching up.
Nicky Wrightson: Natan, you spoke more about organizational culture and team culture in your talk. How do you also factor in what Suhail was bringing into the game there, the aspects around engineering culture into your teams?
Natan Žabkar Nordberg: In which sense do you mean? Because I feel I could talk about this for about four days.
Nicky Wrightson: I was meaning more that you have talked a lot about things that provide team culture at the team level, but the engineering culture, like ship fast or ship carefully, whatever that is. Do you think that the engineering manager is the person to facilitate that culture as well? If so, how?
Natan Žabkar Nordberg: You definitely have an impact. Most people will have an impact on this. Maybe one example that springs to mind was, I went through this and then maybe like four or five other people went through this when we were joining from bigger companies that tend to be a little bit slower and more careful in how they go live. Then we joined a company who was working with production access to the database. If you broke something, you would just SSH into it and then do something and fix something, and it was all fine. Or when we said, we just broke 40% of our customers. "Don't worry about it. It's ok. They don't look at us every day. They look at us every week. It's fine".
First somebody had a conversation with me, and basically told me, if every PR you open never breaks anything, you're moving too slow. He tried to reframe that idea as saying, actually, you need to break stuff sometimes because we're ok breaking stuff. It's a feature, not a bug. In our business, we can break things. We're ok with it. Then I had that conversation with a bunch of other people and you could just see it click and go like, ok. The definition of fast is different than my old company. My old company said fast, but really careful. Here we said, actually, that's not good enough. We need faster than that. That's ok for us. I think that the wider engineering culture impacts everybody on quite a personal level in how you think of your work: what work is good, what work is bad. Obviously at a team level because if this is a misalignment, somebody says, "You just broke production. This is terrible". That's not a good culture you want to have. You're actually actively encouraging that and everybody needs to be aligned with that.
Maintaining Cultural Cohesion in a Remote Environment
Nicky Wrightson: I know Natan as the EM in the remote environment, particularly. In your experience as a remote leader, how do you maintain cultural cohesion? How do you avoid culture by Zoom or Meet?
Natan Žabkar Nordberg: I think with time and intentionality. I think those are the two main parts. You need to make space for it. You need to actually make it a part of what you do. You need to be intentional about it. One thing I started doing actually through COVID because I started managing a couple of new people, is I realized that the usual approach to one-on-ones didn't quite work.
For instance, we started actually making our one-on-ones a bit longer, and saying the first half an hour is just for us to chat. It is not supposed to be the work one-on-one because we don't know each other, so we don't trust each other. I want to hear about what you did on your weekend. I want to hear about your hobbies. I want to hear about how your family is doing. Are you struggling with somebody? Is somebody sick or whatever. That created a space and a shared intention of saying, we're doing this to get to know each other. We're doing this so we can actually work together. I talked about a concept of a session zero in my talk, which is really the idea that you talk about how you work together. I think that's a really important thing to do. You have to sit down and say, how do we work together as people? How do you work together as coworkers? Because those are actually two slightly different things, even if they're very closely related.
An Inclusive Environment, with Different Access Levels (Hybrid/Remote)
Nicky Wrightson: Not everybody is remote and very few people are completely office-based nowadays. There's some form of hybridism in there. Staying on this topic, I'm going to come to you, Matthew. You talk about a lot of ways in which you provide your voice and an inclusive environment. How do you do that when there's different access levels based off different office-based opportunities? Nobody is going to be next door to you at the desk every single day.
Matthew Card: What do you mean by access levels?
Nicky Wrightson: Sometimes people are going to be remote. Sometimes you're going to be in the office. Sometimes they're going to be in the office with you. Sometimes you're both going to be remote. I'm assuming that the BBC is hybrid.
Matthew Card: Yes, we are. One day a week. If I go back to what I said before about I love talking to people, I don't like doing my work. Let me clarify, I do do my work. Part of my work is to talk to people and is to understand them. That's what Natan said about building that relationship is very key. I really like to build relationships with everybody. Sometimes it's really hard. That's why I tend to talk to people a lot more often and then give them access to me. I do make myself available and I'll shift things out of the way so that I am available. Then I will try to travel up to Salford. I don't do that often. Then, for example, my team lead was having a difficult time with some stakeholders and they were going to have this resetting meeting. I made sure I came. I wasn't invited to the reset meeting. What happened is they came to London, I came in just to support them as well. It's about building up that kind of relationship because you have to have that trust. Some people aren't going to trust you, but you have to go the extra mile to understand people. That's what I try to do.
Questions and Answers
Participant 1: My question was around culture specifically within the engineering team. This was touched on a little bit in Matthew's talk as well. Something I've been thinking a lot about recently is how we balance people feeling they can influence decisions and be involved in decisions with the pace we make decisions. I find that quite difficult. I would just be interested to hear all your perspectives on the balance between not every decision being a whole team decision and making sure everyone feels that they can influence in the team.
Matthew Card: You have to set out that we can't all be happy with the decision. One of the things that I do say I got from my line manager was that I'm not here to make everybody happy. I'm here to make people fulfilled in their role, and hopefully they'll be happy from that, but I can't make everybody happy because if I did that, I'll just kill myself. Then what I'm trying to introduce now is, how do we make decisions? We're making decisions on sound technical choices.
Then, as I said, what we would try to do is work out the different types of decisions that are going to be made. Is it irreversible and consequential, or is it reversible and inconsequential? Then we can then decide which decisions to make there. Then hopefully there will be layers of decision-making like RFCs, ADRs, all of those types of things where people can input, and then they can learn, and then we can then make a decision together, and say, we're going to go this way. Everybody's had their input. I think that's what people are looking for is to be heard. Then that goes back to my baseline. If we build up the resilience, then if a decision doesn't go your way, you can bounce back because you're handling adversity.
Suhail Patel: I think extending onto that, decision-making doesn't happen in a vacuum. I think that fundamentally, the people who want to have input into decision-making want to understand the inputs and the context that have gone into making that decision. One of the techniques that I like to run with a lot of my squads is we have a fixed event in the calendar. We call it a civilized discussion hour. This is actually in the calendar. We have it twice a week. Funnily enough, my squads were so against this. Remember fixed recurring meetings, really expensive, especially within a squad calendar. By the time we ran, I think the third one, they were clamoring for a third one in a week. In the civilized discussion hours, sometimes there are decisions that are made at maybe a different layer of the organization or a different part of the organization, and we invite people in to explain the rationale and explain the context behind the decision being made. The decision is fixed.
The decision is made, maybe we've plowed ahead with implementation and things like that. Just to understand and communicate some of the context and maybe some of the input is maybe just a little bit of concern, or things to keep aware of, or maybe an experience that someone has had with a particular piece of technology. Or if it's non-technical related, if it's going to be pertaining to squad processes, or team processes, or how we're organizationally set up, making sure that that kind of stuff is well communicated. Having an avenue where people can come in and feel safe. The civilized discussion hour is a recorded session, but it's a team internal. We've intentionally called it the civilized discussion hour to have a civil discussion about things that are potentially going to be contentious.
The team frames their mind. It's like, we put it at a particular point in the day, the team has framed their mind. They're going in with an open mind to understand what has happened, to hear out the other perspective, and to ask good questions, like relevant questions, deep questions. Maybe do a bit of pre-reading beforehand, and come to a decision at the end of the day, or come to the same rationale that the other person has come to in their decision-making process.
Natan Žabkar Nordberg: You phrased it as a, how do we involve everybody in decision-making? I think that's a slightly incorrect question. I think it's, how do we get everybody a chance to be involved? It's not everybody needs to be involved in every decision, but everybody wants a chance to be involved in the decision. We'll just think about it that way a little bit.
Nicky Wrightson: Or just not left out.
Natan Žabkar Nordberg: Yes, involved, not left out.
Participant 2: I wanted to ask you whether your organizations have the work you do to shape culture as an explicit thing that's assessed as part of your yearly reviews and as part of your promotion cases.
Suhail Patel: That's a great question, maybe most poignant, because we've just gone through our internal calibration processes right now. It's fascinating. It's something that we definitely reward and have as part of our framework. I think it is far more assessed the more senior you get within your rank, at least within the individual contributor track. I think it's maybe more of an expectation for engineering managers. Like the scope of impact that you have in influencing culture, as you get towards junior, mid-level EM, to senior EM, like your sphere of influence is expected to improve from squad to maybe collective level, like a group of squads or tribes, or whatever you call it.
Then as you get towards engineering director, you're expected to influence engineering-wide, and in engineering and beyond, other disciplines as well, like data and many other areas. For individual contributors, it's quite a hard thing to track because engineers are there to mostly ship code and be part of architecture reviews and a bunch of other stuff. There is a different set of expectations involved. I think engineers can be fundamentally involved in shaping that culture within an organization. I think there's a very big missed opportunity if they don't get involved through things like knowledge sharing and internal speaking, and promoting that psychological safety in the words that they use, the language that they use. I don't think it's something that's fundamentally assessed. There's people that are rewarded, but it's not something that is assessed as a baseline in most organizations, especially for individual contributors.
Cordero: The mileage varies, essentially. I think there are some engineering managers that definitely value it more. At The Times, your performance is very much driven by your manager, which has pros and cons. We do have an engineering ladder and whatnot that standardizes that. It does often come to the hands of our engineering managers. I think in platform engineering, which I am in, it's more important because our success is directly tied to things like adoption and whatnot. In that, like my social influence does have to be more important. I think for platform engineering, in my org, it's pretty solid in terms of how it translates to performance. I don't know if that's necessarily the case for a lot of teams.
Participant 3: One of the challenges that I see as an engineering manager is engineers that, from my definition, if they are a good engineer, they are trying to find the flaws on everything. This is what they do. They fix the engineering stuff. They're trying to do their best to get the perfect result. This is not reality because the reality is not perfect. I'm trying to understand, how do you persuade them that the world is gray and not black and white? Because this is my biggest problem. The better the engineer is, the more extreme he's looking for the perfection.
Matthew Card: We probably have some of that issue in my department, or some of that problem in my department. What we're trying to work on at the moment is understanding the types of failure that are allowed and what's not allowed. For example, if you're not following the processes that we've put out, releasing straight to live or something like that, that's not acceptable. Other types of failure, like I've talked about, inconsequential and reversible. If you're trialing something out, you can fail there. That's a failure. That's acceptable.
Then on the flip side, we're trying to get people to understand that it doesn't mean that you have to then go and gold plate something to make it 100%, because there's diminishing returns. With testing, you only test to about 80% coverage or something like that because after a while you have diminishing returns. That's the same with code as well. Make sure you have that good baseline where the engineering excellence is key, but don't go that extra mile to make it gold plated unless you have the time. For me it's about that understanding and being able to play out the scenarios because in some cases it's a good idea to do that. In some cases, it might not be, especially if you're trying to ship faster. It's about having conversations really. Again, I'll just go and speak with people. That's what I tend to do.
Cordero: It was very validating to hear that you said, the better the engineer, the more critical they are, because I am that engineer that's critical. If my manager was here, she would be like, uh-huh. One of the questions that I ask myself and I would like my manager to also ask continuously since we work together a lot, is like, what's the impact of that engineer not seeing those grades, of that engineer being critical? Because I know for me, it can be easy for that lens to lead to low morale.
One of the questions I think that's important when dealing with those kinds of engineers is, what kind of impact are they having? Is it keeping them back? There are definitely times where I feel demotivated at work because I see so many issues that aren't being resolved. I think making sure you have a good temperature on that is super crucial. Because I know, personally speaking, if my manager comes to me saying, I get that you're frustrated with x and y. We have junior engineers on the team. They don't know what is supposed to be the gold standard of an organization. Pointing it out constantly can have that maybe negative effect. You have to hold that in tension with the fact that these engineers also need to be heard. I think that's why, when I have a strong relationship with my engineering manager, we build trust. I can trust that they are doing everything they can to bring my feedback to the people that they need to.
Participant 4: From your own experiences, how long does it take to change the culture? If it depends, what does it depend on?
Cordero: I've worked at a diverse set of companies in terms of domain, and also size, and just type of company. I used to work at Google versus I work at The Times. At The Times, change comes slow. It's because of factors like, it's 175 years old of an organization. Google's 30. I'm older than Google. Anyone who was there in the founding years is straight up dead. Driving change in an organization with so much bureaucracy and so much history is incredibly hard to change. It feels closer to trying to change a country than to change a company. The traditional values that it was built on don't translate well to now. Just speaking frankly, those founding people looked nothing like me. I think it is very much dependent on that history as well. I think also it depends on the values of the company as well. New York Times, it's a media first company.
At the end of the day, our core business is media. Google, engineering is where they came from. If you're trying to evangelize technical change, I found it to be way more receptive to that. Versus at The Times, you need to justify the business case to an extent that you might not see in most companies, and definitely not at small tech startups. Small tech startups, which I've also been in, also a lot easier to drive change just because there might be a shorter history, there are fewer people. Getting consensus is more doable versus you're not going to get consensus at a company that's 100,000-plus people like Google.
Suhail Patel: I think that part of the question you asked is how long does it take to drive that change. I think the answer to that is that it's continuous. It doesn't end. I've been at my company for 7 years now, and the changing of culture changes as time marches on. There are challenges that come into the foray. You meet a diverse set of people. Every single person that joins within your organization fundamentally changes the makeup of your organization, whether you like it or not. No matter what role that they join on, they could be just in the custom operations, or they could be the C-suite.
The level of magnitude and impact is going to be different between the two distinctions that I've made, but every person fundamentally changes the culture. People bring themselves in a very different way. Especially in today's day and age where you recognize most people through a Slack avatar and a profile photo. Things like, how are you doing written communication, how are you doing documentation, how are you speaking to people, what words do you use? All these things are becoming more and more materially important. Many organizations up until five years ago were relying on being face-to-face, and you see obviously a lot of organizations trying to return to that face-to-face model because they've not found an alternative way of being able to work remotely, being able to work remotely effectively. They're using the guise of like, we'll be much more productive in person, or we have much more collaboration in person.
I fundamentally think that they've not found a good operating model. Don't get me wrong, I'm not going to get into a remote working debate. There's probably a lot of values in being in an office and things like that, but there's a lot of flexibility to be offered in the kinds of people that you hire and the culture that you build when you have a culture that is fully remote-able. People can be remote permanently, but fundamentally your company culture needs to change as a result to adapt to those circumstances. I think the change in company culture, the time horizon that it happens at is continuous. It changes every single day.
Natan Žabkar Nordberg: I'll give you a formula because I'm a math guy at heart. Take whatever you think the number is, multiply it by the willingness to experiment and change, and divide it by the strength of inertia in this company. The stronger the inertia, the longer it's going to take. The more willing they are to change and experiment, the faster it's going to be.
Matthew Card: You know when you talk about change in culture, were you saying for you to change culture or for the company to change culture?
Participant 4: The culture across the company.
Matthew Card: Change by you, or?
Participant 4: Both.
Matthew Card: I just wanted to bring a bit of, just say sometimes culture won't change as well. It depends. It won't change. I always go back to resilience. That's where the resilience comes in, and the emotional intelligence. You have to know or you have to then work out how much time you're going to spend on that. I'm a big Simon Sinek fan. Simon Sinek says something like, if you're in an environment that's not going to change, don't try to change it. Just do what you can within that space. What I then say on top of that is wait for the types of energy to come your way to then band together and then keep pushing forward. You have to look after yourself. That's that emotional intelligence, as well.
Participant 5: I was curious if you've experienced someone at a senior level, like VP or director, not modeling the behavior that you'd like to see. I'm not talking really toxic. You think about Alicia talked about spectrum of values. Someone who's maybe in the middle or slightly on the wrong side of not modeling the cultural values that you'd like to see. Have you experienced that and how have you dealt with that?
Suhail Patel: I'd be lying if I said no. I would be fundamentally lying. I'm not going to do that on this stage. Yes, for sure. There can be different people on different sides of the spectrum. Maybe someone who's joined relatively recently or brought in antipatterns from their previous organizations. A lot of people get shaped, especially as you have tenure within particular organizations. For example, people that come from Meta, they're very well-meaning. Not to disparage anyone from Meta.
For example, their culture is like, move fast and break things. I know they've changed this motto relatively recently. That culture doesn't fundamentally align with how we develop in engineering. We move fast as well, but not to the extent where we're going to value breaking things and changing all of the order. You come from Amazon, it's like API first, API or death is probably the Bezos commandment, or like, disagree and commit. The leadership principles are ingrained in your head. Especially when we hire a lot of people for the kinds of organizations that we attract people from, they are coming from big tech. They are coming from the Amazons and the Metas and the Googles and things like that. They have been immersed in those cultures, indoctrinated is the word that I use, for a long amount of time, 7, 8, 9, 10 years, a full decade in those cultures. They are so used to being effective in those ways of working.
For them to come in within Monzo, fundamentally it's a complete shift, and they believe that in order to be effective, they can repeat the same formula. Copy what I did at Google, apply it to a smaller scale, paste it within this organization, and that fundamentally does not work. Those people are set up for failure. This is not something that they are told on day one. This isn't any sort of handbook. These people, well-meaning, well-intentioned, to be clear, sometimes not as well-intentioned, in which case, like, should look at offboarding them.
Most of the time, well-intentioned. They need to be given feedbacks and prompts. As an individual contributor, I don't see it as part of my role. I think Sarah asked the question, is this something that's measured in progression? If I spot something, I don't have any reservations in reaching out to that person and providing feedback. Like, "I think you could have worded this better, or this doesn't align with how we communicate things within Monzo. You're doing this thing wrong, or fundamentally incorrectly". Often, I speak from a position of privilege because I think I have the credibility within my organization that people respect my input. I don't think this is a formula that can be repeated by just anyone. I definitely appreciate the privilege that I have. I'm very well-known within my organization, also very well-known publicly.
People have seen the body of my work, when they see me pop up randomly on Slack, they're going to do a bit of research before they say, no, I fundamentally disagree. It is my responsibility. I do take as a responsibility personally to make sure that this sort of feedback is given. Fundamentally, people are receptive to this feedback. I think it's when they're not receptive that there is a problem. Fundamentally, people are receptive to this feedback, and align themselves on the right side of the line once they understand that they can't just copy and paste the formulas to success that they've had. They need to adapt those formulas.
Nicky Wrightson: It's all well and good talking about culture. How do we find the right culture? We go through interview processes. Asking a company, what's your culture like, is the most useless question. Because most people aren't able to articulate a real culture. You'll get some nonsense back that's just like a handbook. Do you have any questions or strategies in trying to determine a company culture? I recognize that some of you, you've been in your roles for a while. You may have heard other people's strategies and questions to understand the culture at your place.
Natan Žabkar Nordberg: There are a couple of questions I try and ask with the interview process. A lot of them are questions you can only really ask of managers or somebody like that. Questions like, how do you manage underperformance? Because I think that tells you a lot, especially at a specific action. Are they just like, we fired a person, or are they like, we really work with them, or somewhere in between. I find the question of, why are you hiring for this role? Especially if it is because somebody left, to be quite illuminating. Because it can show you, first of all, why somebody left. Second of all, how they talk about the person that has left. That one you can also ask to more like the ICs and engineers and staff that is around you. Sometimes you get what's called a less filtered answer, because they're less prepared for that conversation.
Outside of that, I've been primarily joining startups, so I had an opportunity to talk to the founders, usually. I can just ask them about, why did you fund this company? Why did you start it? What do you care about? What did you look for when you went looking for funding, for money? Who did you approach? Why them? Why not somebody else? Things like, who do you look up to? Who's your mentor? Things like that. I don't know most of the people, so they say, person X. I'm like, I don't really know who they are, but what I care is about how they talk about them. They talk about them as, yes, they've given me this really good advice. I really respect them. When talking about the silver bullet that just tells them exactly what to do, and that's the only reason why they like them, because it was beneficial to them. Those are the kinds of questions I've usually asked.
Cordero: In several talks that I've heard, the topic of interviewing came up. I think it was mostly in the context of the engineering manager and how they do interviews. One thing that was common was about having strong rubrics for evaluation and whatnot. Another thing that was said was, you're being interviewed twice, or you're on both sides, rather. I actually do have a rubric. Before every interview process, I put together the things I'm looking for. Then also just very concrete questions I have. I care a lot about diversity and inclusivity. I will straight up ask my potential manager questions related to that. For a lot of these questions, I'm not even necessarily looking for a right or wrong answer. When you ask, frankly, more uncomfortable questions, how they react, I think, is honestly really telling. If I'm asking about, how do they go about managing underrepresented people? They choke up, and they don't know how to speak about them. Then I'm like, good to know. I do actually have a rubric. Then that also allows me to compare the diffs between companies. Yes, I do. I even translate it to a spreadsheet and everything.
Matthew Card: I have been in the BBC for 15 to almost 16 years now. I haven't really got that many questions I asked. What I did do, I've navigated through the BBC quite sharply towards the end over the last 5 to 6 years. Then basically what I did is, there was a talk where this person was talking about the difference between employment and deployment. The person goes on to say, we've been all taught to get employed, but have we talked about or learned how to deploy ourselves? What I try to do, I try to find the right balance between employment and deployment. My last line manager, I sought them out. That's who I wanted to work for. I made sure I got to work with them. I deployed myself there, and it worked out very well for me.
Suhail Patel: Any time candidates ask me a question, especially in an interview context, I always preface my answer by stating, this is a manicured answer. I am here on behalf of my company. On company time, I need to give you a manicured answer. I can be honest and say not everything is perfect. I'm going to give you the manicured, the positive answer. I come in with a stance, because, ultimately, I want to hire this person. No matter how they did in the interview, ultimately, we might want to hire that person, because my input is going to be one input to how that person performed. It might be that they are the perfect candidate. In which case, I want to leave them with a positive experience. I want to give them a manicured answer. To find out about engineering culture, ask people that you're not being interviewed by. Sometimes organizations do this and say, you get to speak with some of the people during the lunch break and stuff like that. That I feel is also quite manicured.
Looking at the periphery, you get to meet a lot of engineers at a conference. Or you can reach out to them over LinkedIn and things like that. Most engineers have been pretty telling in how their company cultures are like. Sometimes you get a bit of a disgruntled view. That's something that you need to have a rubric for, as Lesley mentioned. Also, look at the company persona on the outside. For example, you can glean a lot of information from their engineering blogs and videos that they put out. People that represent themselves in conferences. How do they behave in the wider engineering community? I think you can glean a lot of information. Do they expose themselves in the wider engineering community? Things like, for example, transparent salaries or publishing their progression frameworks and things like that.
Even talking about progression in a setting which is well understood. These are fundamental things that you can ascertain. If they don't do these things, make sure that you get good, coherent answers when you ask these things within an interview context so that you feel confident that you're going to be well taken care of. Because if they're not willing to share this information externally and they're not willing to share this information to you as you are applying for a role, you're putting a lot of time investment in and a lot of responsibility into someone else's hands. I think that is a pretty telling signal.
See more presentations with transcripts
