Episode 13 - Transcript

About Engineering Culture Health Checks with James Bedford

Welcome to CTO coffee. Today I am talking to James Bedford. James entered the tech industry in a non-traditional way. He started out working in construction before then switching to being a developer. James has held several roles at several companies already. And since October 2019. He’s working as an engineering manager at Monzo. The modern UK bank, and so welcome, James. So great to have you here.

Thanks, Benjamin. Good to be here.

So you maybe want to tell the listeners a little bit about yourself.

Sure. So as you said, I’m James Bedford. I live in the UK, I work at Monza bank, which is a digital-only bank. I work primarily remotely. But our offices are based in London. And as you said, I had not a particularly traditional route into the tech industry. So after school, I started off as a construction worker. And I did that for most of my early 20s, before teaching myself to code through Free Code Camp, and started doing some freelance work, some contracting before landing a couple of full-time jobs as a front end developer that led me on to leading an engineering team at a company called Mango solutions. And from there, I applied to Monzo. And I’ve been at Monzo for eight months as an Engineering Manager.

So this whole topic of, let’s say, non-traditional routes into tech is I believe, quite dear to your heart. You just recently started sending out a newsletter again if I like to read that correctly. Yes. that’s right. I can recommend very much been a subscriber. How do you say episode key? No, not an episode but from edition number one. edition one. , I think you maybe want to share a little bit about your perspective there like what? I think that would be interesting.

So, I guess I feel so passionate about this topic. Because when I was sort of teaching myself, I was meant I was met with some resistance regarding specifically people that didn’t necessarily have a computer science degree. University was never something that was on the table for me. And so I think I found that quite a challenge to deal with, I guess when I was attempting to make this journey in tech and being told that that was something that potentially could hinder me. Even though I’ve managed successfully the break into the industry, it’s an attitude that I still see today. And generally, I feel quite passionate about at least standing up for people that haven’t had a traditional route into the industry. And because it can be done, and we should be offering more support to these people that maybe are being put off by some more traditional views. And I focused my newsletter around this diversity in tech, as well as helping people make that journey and break into the industry.

As I’m helping teams to, recruits to grow and all that, so this is also like a very interesting topic for me. From from your point of view, like when you say you try to help people like, what is like your, I don’t know, number one advice may be or what is like the typical thing that you tell someone who tries to enter the industry from a non-traditional route, like, how, how can they make their contribution better understood.

Typically, and I used to, when I used to mentor people that were going through this journey, there was always the same sort of topics and themes that came up and the same problems that people were having is that if people hadn’t gone to university, they found it harder to showcase a body of work when they started applying for jobs. And so raise Say two people one project, or one fully completed project that you’ve put a lot of time and effort into. And as well as active sort of contributing to open source projects is the best way to build that showcase of work that you can do. I don’t think certainly I wasn’t aware of open source when I was sort of making that journey myself. And as I’ve gone forever, I’ve understood how much potential it is for people to use that to build a showcase of work that they can use to get into the industry. As well as that, I guess, my advice for people making that journey is just to have done your research before you start and have a good understanding of the lay of the land in regards to what software what programming languages, you need to learn, to focus on the area that you want to I see so many people that maybe haven’t come from a university that are teaching themselves to code, the things that programming languages are something to collect. So you learn to do something with one and then move on to the other. And it doesn’t necessarily work like that. I tell people to do the research. So if you want to be a front end developer, HTML, CSS, JavaScript, and to focus on building the fundamentals without worrying too much about moving off on planning something else, I think that’s my advice. I give a lot of people now,

I can’t imagine that. I would sit in an interview, like interviewing someone and they would be able to like you said, Show up there. One thing that they did, that already would make a lot of difference.

I see that people maybe hold back from applying for a junior role because they don’t have a portfolio of projects. And the average person isn’t going to have time to make 5,6,7 projects from Start to Finish. It just is not realistic if you can put your effort into one thing that you can utilize and showcase and show people what you can do, and that’s my ultimate advice for people that are starting out.

Cool. Very, very good. So we kind of got to know each other because via your colleague, Sally Lake who appeared on another podcast, which I’ve kind of forgotten the name for sorry, Sally. And there she mentioned that Monzo does a lot of port. I don’t know if it’s a lot that you do health checks for the year engineering culture and so, that kind of like piqued my interest because I find it very interesting how, as a company as an organization as a team, you can like make the intangible like an engineering culture, like more tangible And therefore, like evolve more consciously. And the intangible Of course, being an engineering culture. so we kind of like picked out this as a topic for them for this recording. And so maybe you want to give a short overview maybe that’s like, what do you use health checks for? And what is the purpose that you do at Monza?

Sure. Yes. I think before I go too deeply into the sort of process of health checks, it’s useful to maybe get an idea of the lay of the land of how Monzo is set down as an engineering culture. And so the company is split into what we call collectives, which are essentially verticals, each focusing on a different part of the business. Each collective has engineering squads. So they’ll be, they’ll be back end engineers, sometimes front end engineers or web engineers, QA engineers or designers and they work within a squad, and all chase one goal that’s relevant to the collective that is authentic. And where engineering managers sit in that is, we have a few engineering managers per collective.

We’re not necessarily assigned to one squad, but we look after certain squads. And so for instance, in my collective witches operations, there are six squads, and I sort of look after two of them. So that’s just to ensure the welfare of the squad to make sure that there are no blockers to make sure nothing is slowing them down and to make sure the team is performing to the best of their ability. The idea of health checks was originally brought to us by one of my or two of my colleagues. So Alan and Otter who are engineering managers in a different collective, however, we share ideas amongst the engineering managers as a group they came from so Alan worked at Spotify before, and I was worked at Atlassian. We’re both very hot on health checks, and engineering culture. And they bought their ideas from these cultures and sort of created a new model and relevant to Monza. And that’s something that was given to the engineering managers and we’ve taken them away to our own collectives, and sort of tweak them and got to use them. And that’s, I guess that’s how it started. The purpose of a health check is just to make sure that the team that you’re looking after and performing the health check with is happy that there’s nothing that is slowing them down. And generally, they’re a happy and healthy team.

So what are like possible, like metrics, I don’t know, what do you call them? Metrics, that you evaluate within the health check or what are like the dimensions, maybe that’s a better word that you’re trying to gauge with, with the health checks.

So we bring our check to a squad, and it’s made up of a set of questions, each regarding a different topic, and each member of the squad can then vote positively and negatively, or that they don’t feel any way particular about a certain question. So really, it’s a positive answer, a negative answer, or just a neutral answer. And that’s, I guess, the metrics behind the questions. And so we work through the questions as a team. When we get to the end, we’ve got a set of results. So what we’re looking for basically is negative results. And that flags up an area that we would potentially need to concentrate in or to dive a little bit deeper into as engineering managers. And as a team, we found that it’s useful for the team to be aware of the results as well. Particularly if there’s maybe one or two members of that team that are feeling different from the rest of the team. And the rest of the team can help out in that area or maybe help the team members that are feeling more negative about a certain statement and make their life a little bit better.

When you just said that you work through the set of questions as a team. Do you like to answer the question? Do like to fill out the questions. Give the answers, like in a setting or in a session sorry, in a session where you sit together as a team or going to or is it like a question that you send around like a Google forum or I don’t know.

So originally, it was an exercise that we did as a team. So an engineering manager would sit down with the rest of the squad, there’d be a set of questions, they’d work through them one by one, allowing the team to vote on each question and then having some discussion after they voted, however, we found, and this was something specific to our collective. My other colleague, who is an engineering manager, and the operations collective that works alongside me, Lucilla. And we devise the method to undergo these health checks where people can vote anonymously. And this is to ensure that if people maybe weren’t feeling psychological, psychologically safe enough to be truthful with their answers, that we get a more, I guess, honest result. And so the method that we use now is people have sent a form make them work through the questions. And we do that as a group, but people are logging their answers online so no one’s aware of anything else that anyone else has voted. And we wanted to avoid a situation where specifically a question like I can trust my squad members to get the job done. Maybe one person might not trust the squad members but wouldn’t feel safe enough to give a negative answer to that because they’d be the ones that had given a bad result and it’s not a comfortable position to be in for most people I would imagine. And so being able to vote anonymously, but still getting to I guess to see the end result of that has been super powerful.

You’ve already kind of like mentioned the question just now with like, Can I trust my squad members to get the job done? I think it was. Can you maybe also share like one or two other questions like to get a feeling for the Culture, I think you, I think, at least like the podcast that I listened to where Sally appeared, was about, like engineering culture, and I think, and I’m not hundred percent sure of like, what, what are you trying to measure? Or what are you using health checks for? Like, is it for the culture? Is it for something else? Or both or more?

So it’s, I think, primarily, it’s for the culture. And so whether people are feeling included, whether they feel safe to be themselves within the theme, but it’s also for performance. So focus on more technical things. Say for instance, and people will not, I’m happy with how we manage our technical debt as a team. Our code is safe to deploy. And then amongst more, I guess, culture-based questions like I feel safe to be myself or I enjoy what we’re currently working on. Equally as important, I think, if someone didn’t feel safe to be themselves in a team, that would be concerning. Equally, if people weren’t feeling safe to deploy their code that would be concerning. So equally as important for us Monza has a really great culture of diversity and inclusion. And that’s super important. And this is why we’ve included it into the health check is if people aren’t feeling safe to be themselves if they’re not feeling included, or if they can’t trust people to get things done, then we would not want to know about that. And that’s something that we’re quite well placed as engineering managers to be able to solve I guess,

Cool, so how can or how often like to us these are let the people fill out the questions. Is it like once a month or once a week or?

So we’re, we’re aiming now to do it roughly once a quarter I think if we wanted, if there was a particularly bad result, I guess, or if there was a tough result. Or if a team were maybe in not such a good space, we would want to do it more to make sure that we’re on top of this thing, that as a default, it’s run once a quarter intention is that engineering managers facilitate the needs, to begin with, but eventually, it will be something that we can hand over to squads to run themselves with, amongst engineers, and a product owner, or something that they can do away from relying on engineering manager to facilitate

That makes sense, as it was all these kinds of things. You really have to figure out a way that’s specific for your team, company, or collective definitely. So then there would make.

Sorry, I guess I wanted to add to that because I think that’s really a good point. We’re not expecting the results or even every team to find these super valuable like we just said, it’s about finding what works per team. So whether one team maybe don’t need that every quarter or one team feel they need it once a month. It’s about finding what works best for that squad. Whether they like it as an exercise or whether they don’t I think that as well, that’s super important. It’s been more effective for certain squads than it has for others. I think squads that are super high performance and really trust each other and have a positive outcome on each question. It’s, I guess it’s a confidence boost. But you don’t necessarily get the value from that from as opposed to a squad that maybe you’ve got some negative answers thrown in there or maybe aren’t quite as hot on a certain question as a high performing team.

19:00 I think one thing that I struggled with the most when thinking about like how can a team or any organization of any size like work with such a set of questions such as health check, is that what do you do when you actually I mean, that’s kind of what you want, right? You want negative answers once in a while to and even if it’s just for knowing that, not everything is super awesome. And people are still, like you said, feel safe enough to give negative answers. But do you already developed any kind of like strategies or do you have a feeling for how to handle like a negative? answers across the board. Like if one squad or team would come out and say like, okay, we don’t feel safe enough to or if we feel like, I like this technical debt thing because it’s sold So broad. Like, we don’t feel like we address technical debt properly. do you then just go to the team and ask them like, Okay, cool. How can we handle it?

It’s definitely where we’re very keen to include the whole team is not something that management is just going to take away and then impose, like, a strict new rule on the team to maybe show them a way of correctly handling their technical debt is something that we want to work out together. And so we have quite in-depth discussions about some of these points after, for instance, one of the first ones we ever did the team, it came out that they were quite unhappy because they didn’t have a product owner in that instance. This was something that the team was more than happy and open to speak about. And then that was resolved. More I guess when the answer is more involved in something like whether people aren’t feeling safe. We put a huge amount on emphasis as engineering managers on building trust with the people that we are looking after, or our reports. And I wouldn’t. I would like to think that people if they weren’t feeling safe in the team, and that was pulled up as a result of one of these health checks would be able to speak to a manager about it.

And that’s certainly as a manager, that’s my priority and building those trusting relationships with people. And so even if they didn’t feel safe in talking to the team, and they come to me, then that’s something that we can work through together. It’s a very open, transparent culture. So if something isn’t right, we want to talk about it and fix it as a team. To be honest, as of yet, there hasn’t been too much that’s been thrown up there. It’s really concerning or isn’t something that we haven’t managed to sort out working together. And we so on the results we log in, we have a, we have a like a system set up on the app notion which we log all of the results for. The health checks in is worth noticing. Now the other squads don’t see the results of other teams’ health checks. This is something that squads can see their own results. And then engineering managers can see the results as well. They think that breaks away from people comparing themselves to other teams and maybe feeling not doing so. Well. That’s not the intention of this exercise. It’s just to focus on a certain theme and help them overcome problems.

When it also just occurred to me that its kind of just doing that kind of like yeah exercises you just call it like I’m doing these health checks. And the way you do them is already like also influencing your culture. Like you can show to the team just by the way you how you do these kinds of things like these health checks, kind of questions you ask them that already is a very strong signal to any team, to anybody in the organization like okay, this is what we value. And we evaluate this way of dealing with this, whatever comes up like we want to talk about it openly and you can really, you can trust me. I mean, this is always like a semi problematic not problematic, but it’s easy to say like, you can trust me. But it’s harder for people than to do that.

Definitely. Now, the fact that the company is so open was one of the things that drew me to Monza is something that they shout quite loudly about it. And if you read through any of their blog posts, the fact that they hold transparency and inclusion, so close to their heart as a company, and it is so important in their culture was appealing. And throughout the company, that’s, it’s, I guess, it’s continued to be shouted about. So even at team level exercises like this, people understand that. That’s the important thing. Which is awesome to be honest, like as a coach, you wouldn’t want anymore and it’s great.

Cool. So, you already mentioned the bit that. in the beginning, you, you kind of facilitated these, the answering of the questions. And by now you switch to a more like questionnaire model where everybody answers on their own. Was there anything any other way or dimension how the checks already, like evolved since you introduced them?

And I think the only thing is the way that we manage the results, the checks have stayed very much the same. We didn’t want to, I guess, make exercise more complex than it needed to be. And I think one thing that we’ve evolved is we could and we could do these health checks as a squad That was great. That’d be a note-taker. Whilst we were going through this exercise, and then those results, it would be hard to maybe communicate them to other engineering managers that were working in the same collective that may be managed some of the people that were in that team that was getting a little bit lost. So as I touched on before, we have a system in motion that houses all of these results. So there’ll be a, so there’s essentially a table that lists all of the health checks as and when they happen, and what we’ve, whether the squad is happy, whether they’re neutral, whether they’re unhappy, and then we house all of the notes in there. So it’s visible to all of the engineering managers, as well as the team have undergone the health check. That’s the only thing that we’ve changed, other than making the health checks. Anonymous. We haven’t found as of yet, there’s anything else that needs to be changed. And we’re really happy with the way that they run, and as I said at the start, it’s sort of the brainchild our guests from my colleagues, Ellen and ours who have come from engineering cultures where this has already been developed. And they’ve sort of taken the best bits and then created our own health check system to speak and it’s been really really effective.

I kind of like have this other question in my head, but I feel like you kind of answered it already, which is like maybe there is something else that that comes to mind. So, when besides this example, where you said like a team was missing and product owner so that was like one thing that came out of the health checks like when kind of changed that you and were Was there any other thing or aspects any change that was you You feel comfortable talking about of course, that came out of these checks.

Certainly. And so another thing that’s come out of the health checks and from the culture as a whole about people being open, and people should be allowed to be themselves in a team. And so one of the things that we’ve been doing, and one of the teams that I work with is, so, at Monza, we have what we call “Work With Me” documents, and I’ve not encountered them anywhere else. But basically, they’re sort of a summary of exactly how people like to work. So their working hours, whether they’re going to be in the office, whether they work from home, and the sort of hours that they like to focus on whether you should walk up to them and speak to them when they’re sort of got their headphones in really specific things.

I think that Now, specifically, that people are working from home with the pandemic that’s spread in the world. This has become more important. So people that have children, and I’m sort of juggling caring responsibilities with work responsibilities, and we wanted to become a little bit more transparent and open about how each of the team members wants to work. And so we’ve taken an action as a result, to update each of ours. What we’ve asked documents and mine hasn’t necessarily changed so much. Personally, I work from home anyway, but people in the squad that maybe didn’t work from home now my hours have changed now their parenting during the day, and that’s been something else that’s been changed and that’s really effective. And it just adds to the culture of inclusion and work. In with people and allowing people to choose themselves, we wouldn’t want anyone to ever feel as though their parenting responsibilities weren’t necessarily as important as their work responsibilities.

And we want to cater to that. And we don’t want maybe the team to be hassling someone, when unnecessarily because if they’d have been open and had this sort of information that they don’t work between 12 and 3, because they’re looking after the kids, and someone sends a message during those times, and I think that’s super important as well, especially now, but. All the time. It’s just a good practice that has come out of probably a bad situation that we’ll look to continue moving forward. As I said that that’s come out of a health check. People wanted to feel a little bit more aware as to how to cater to their members, which is just really, really nice to see that people are thinking right now.

That sounds awesome. Like cater towards other’s needs. Which is basically what’s behind that I guess you just talking about like the academic and your different way of working I’m reminded me that I assume you view as a manager doing like pretty a lot of one on ones and regular one on ones with your people on your squad and has the have the results from the health checks or the health checks themselves somehow been like part of I guess they probably have been part of one on ones but yeah how many maybe how some of your one on one conversation that you have with people how they might influence change or affect that the health checks or maybe even some of the questions that came out of like Well, some of the questions that you then used in the health checks today maybe came out of conversations with people, like maybe even one on one style.

I think that’s, that’s definitely something that we’re probably going to think about. So we’re due to do health checks in a few weeks. So we haven’t done one since the pandemic. And so I think, going back to sort of one on one conversations, I think generally the feeling with people is that they’re I think people specifically that don’t have the experience of working from home may be full time. The thing they seem to be struggling with at the minute is overworking and it makes it all the easier just to pick up your laptop, and, and sort of sit on the sofa and work until seven-eight o’clock at night. And that’s something that we really want to try and avoid I think it’s is easier to avoid doing that when you’re commuting. And when you’ve got the sort of morning commute and afternoon commute and people around you to say, maybe you should go home now if you’re in the office quite late, and that seems to be something that’s come up consistently. And that’s what I’m thinking about at the minute. And that’s something that I would like to include in the health check for the next round.

But the beauty of it is, is we can add and take away questions that are maybe more relevant at a particular time, but that’s definitely something that’s relevant now. That might not be the next round. There is something that I’m thinking about, and I’m looking to change purely based on the pandemic. Cool. So, yeah.

I think I have a much, much better idea of, how sticks can look and how they can be used. And it even sounds easy to get started with actually, like, before I had this maybe way too complicated idea of them in my head on how to introduce them and so on. But actually, it sounds pretty straightforward. And so often with these things, I think, the beauty lies in the process of doing it. And also, of course, in the actual result, but also on the simply the way of doing it. Definitely.

And I think the thing to remember is if you’re announcing anything, and it’s just to be we make a really big effort to highlight what the reasoning behind these checks are and what they are and what they aren’t and to go over this every time we do it, and so we want to specifically say what this isn’t doing. For example, I have a few notes on the side that usually I run through with the team’s survey results. Not to draw general conclusions from without deeper discussion. This is not a means of grading squads. This is not a means of comparing squads to one another. And this is not meant to take the place of regular discussions about how to improve within your squad or within the collective. I think the concept is easy to introduce, and it’s easy to pick up and get started. I think the thing that has the potential to go the most wrong is people not feeling safe. If you’re introducing maybe exercises and rituals without explaining exactly what they’re for and what the outcome of that is going to be. Because if I guess if you just sat down with a team and went through these questions, people could feel nervous exactly about what the intention of that is, and whether those people are going to be reflected on badly if the outcome is bad. Again, that’s not the intention. And we’ve made it explicit But that’s not what we’re trying to do with the teams. So it’s very easy to sort of introduce and get started with them. But I think attention should be put on how they’re delivered exactly what the expectations are when you’re doing.

Exactly. And somewhat similar to what I said earlier already. Like, I find it beautiful, like all the words that you just used in, they can signal they can send a very strong signal to words. People like okay. Yeah. We’re really thinking about what we’re doing and we’re really trying to, to make this right to really create a culture of trust and that’s not judging and not blaming and all this and like I said, though, the way you introduce it is as important but also not complicated. Like I mean, simply thinking about like what is the intention? This and writing it down. Like doesn’t have to be like a, not even a like a two day or one-day thing. It’s simply something that you can sit down and write down and maybe reflect on a little bit with a colleague or so. Yeah. So again, a super interesting thing. Thank you very, very much for the insights that were very, very enlightening.

Not a problem. Thanks for having me.

Any last words that you want to share with the listeners? Maybe you can plug your newsletter.

Cool. And so if you want to see, I mean, I’m writing openly about diversity and inclusion engineering culture. And so if you want to subscribe to the newsletter, that would be massively appreciated. I think there’s a link to it in the show notes on in the show notes. It’s James with two E’s at Substack dot com and releasing an article each week, purely based on engineering culture, and that would be massively appreciated. If you could subscribe. That’d be awesome.

Cool. As I said, I’m already subscribed and you should too. Of course, you meaning you the listeners. Thanks again, James. That was very, very interesting and very much appreciated. Have a good time and take care.