Jack: Good afternoon everybody, and welcome to our Made Tech Talks webinar. Today’s topic is “How to build a successful engineer academy”. Our speaker is the wonderful Clare Sudbery, one of our Lead Engineers here at Made Tech. Before I hand over to Clare, I’m just going to run down on how today is going to work. Once I finish this intro it’ll be a 45 minute presentation from Clare, followed by a 15 minute Q&A at the end of the presentation. So if you have any questions for Clare, please be sure to add them to the Q&A function found at the bottom of your screen, and at the end of the presentation we’ll endeavour to answer as many of your questions as we can in that 15 minutes.
I should mention that after this webinar we’ll be sending out feedback forms to all of our attendees. They only take… very very short, they take about a minute to fill out, and they help us to improve our webinars moving forward. We’ll also be sharing a little bit of information about what we’ve got coming out soon, so stick around at the end to find out more. I should also mention that this webinar will be coming with live subtitles, so if you want to access those click the ‘cc’ button found at the bottom of your screen. Information on how to access these subtitles will be posted in the chat function throughout the presentation, just in case you missed it on the way in. Last note: This session will be being recorded. And so, enough from me. I’m going to hand over to Clare. Clare, do you want to take it away?
Clare: Thank you! Okay, so I’m just going to share my screen, and as well as that I’m also going to make sure that I can see the chat window. I’m used to doing talks, it’s been a year now, but I used to do these talks in front of actual people that I could see in front of me. The way we have things set up, I can’t see you, and so it’s really helpful to me if I get feedback in the chat. So if people kind of chat to me as we’re going along, just send me a smiley, tell me if you like a particular slide – that helps me to know that there are people out there listening to me.
Okay, so I’m going to leap straight in. Hopefully you can see my first slide. This is just telling you what I’m going to be talking about. I’m going to split the talk into three parts: I’m going to talk about what we do before we run an academy; I’m going to talk about what happens during each of our academies; and I’m going to talk about what happens afterwards.
We have been running academies now since 2017, when we had two academy programmes, and then in 2018 there were… sorry not two programmes, we had two students. So in 2017 there was just one very small academy programme with two academy engineers, and then in 2018 we ran another one – this time with six engineers. In 2019 we ran two academies, each with six engineers, and last year – 2020, during lockdown – we ran another academy, this time with 12 engineers. This year we’re planning to run at least one academy with 16 engineers, so we’re gradually growing.
Let me talk a little bit as well about my background. I’m closely involved in the academy. I do most of the teaching, and I put the programme together and prepare the materials, and also use all the materials that have been prepared by my colleagues. I am an ex-teacher, I used to be a high school maths teacher, and I have to confess that it didn’t go terribly well. It was actually in a gap in my IT career, so I’ve been a software engineer for 20 years now, more than 20 years, but there was a gap in the middle. I was a software engineer for 12 years and then I actually quit being an engineer and became a high school maths teacher, and it was hard! It was very hard. Much harder than I anticipated to persuade teenagers in inner-city Manchester schools that maths was fun. I thought the fact that I find maths fun would be enough, but it wasn’t. I mean most teenagers don’t even want to be in a classroom, let alone learning about maths, and so I didn’t last very long as a teacher.
I came back into the IT industry, came back as a software engineer, but I hadn’t lost the bug for teaching, and so more and more I found that I was doing a lot of mentoring and informal teaching. Gradually I made that more formal, and now I’m teaching on our academy programme. I’m still also an engineer but I’m also teaching on our programme, and it’s fantastic for me to be able to teach people who really want to be there, and my enthusiasm is now matched by their enthusiasm, and the combination of the two really makes a difference. I have to say, I really do enjoy teaching and being involved in our academy programme.
So, I’ll tell you all about how it works, and maybe I should start with that actually because I’ve said that we have an academy, but what is an academy? For us, what that means is that we pay people a salary, so we recruit people to join our programme, and then we pay them a salary for a 12-week teaching programme. I think it’s more or less always been around about that length. It has varied a little bit as we’ve kind of progressed, but I think it’s always been around about 12 weeks. So we teach them full-time for 12 weeks with a salary, and then at the end of that we offer them a job as a software engineer. There is an assumption that they will stay with Made Tech and they will become software engineers and work with us to deliver software for our clients.
So, the first step is recruiting people to join the academy, and there are a few principles that we use there to make that bit work. I think one of the most important ones is that we make it attractive. We make it a desirable proposition for people, and there are a few ways that we do that. We make it clear that we will be providing support throughout the process. We are deliberately very open to people who don’t have degrees, and don’t have degrees in IT – sometimes they have degrees but not in IT. We take on very few people that actually have degrees in IT, where part of the point of the academy is that we’re trying to open out the profession to people who haven’t followed the traditional routes. So one of the things that we’re very clear about is that we will provide them a lot of support, because the people that we’re taking on do have some coding experience – we don’t take people that have none at all. We want them to have some experience, but it tends to be quite light, and it’s quite daunting for them, so we make it very clear that we will provide a lot of support. We also make it very clear that the focus is on learning – that that we want them to learn. We understand that they won’t know stuff. We want them to learn. We want to scaffold that for them. Another thing that we do to make it desirable is that we share resources all the way through the process, so we point them at places that they can go to learn more. Whether or not they’re successful with us, we give them support in preparing for our interview process and finding resources to help them get ready for that. So that’s the first principle is that we’re making it attractive for them.
Then the next principle that we follow is that we go to them. We don’t wait for them to come to us. And part of that again is about the fact that we are deliberately trying to open out the industry to people who might not traditionally apply for a job in IT. So we’re deliberately going to underrepresented groups. So we’re going to organisations and groups that are specifically targeted at people who don’t traditionally get involved in IT. So for instance, in fact one of the people who helps to run the programme, Charlene Hunter, is very closely involved with Coding Black Females and other organisations like that, but they’re not the only ones. So we market to any groups we can find that target diversity, and then we stay in touch with them. So we keep them updated as to where we are in the process, we remind them of what’s going on. That applies to diversity groups, that also applies to social media, it applies to various meetups, that we let know that this is happening. So we get in touch with them and we stay in touch with them, and we try to make the process very clear and transparent as to exactly what’s involved.
And then the next principle that we follow is that we make the whole recruitment process multi-layered. What I mean by that is that there are several steps in the process. Now part of that, being perfectly honest, is that we do want to dissuade people who aren’t prepared to put a certain amount of effort. A part of that actually is about what we don’t want – is for people to just sort of spot an advert and think “Oh yeah, maybe I’d like to be a software engineer” without really knowing whether they do want to or not. We want them to put a bit of thought into it. We want them to have already engaged. We want them to have already learnt a bit of coding. We want them to be pretty sure that this is a career that they want to follow, and that they are prepared to put a certain amount of effort in. It’s not a passive process – we want them to be active learners. So part of it being multi-layered is that we will lose people along the way, and we have easy ways of filtering people out at every stage. So we try to make that objective – so we use data points and scoring elements, we give people scores at every stage of the process and we filter out the people that don’t get the high scores or that raise flags. So for instance, there are lots of touchpoints along the way where we’re actually having contact with them, and we are paying attention to how they interact. So for instance, if they don’t do well at any stage of the process, what we don’t want to hear is “Oh, it’s not fair!”- what we want to hear is “What could I do better next time? What could I do differently next time?” – We’re very keen on people who, if they don’t get through, ask for more resources and then try again the following time, and we actually offer mentoring for people who don’t get through, to help them to try and get through next time. We want to nurture passion and interest and enthusiasm, and we also… what one of the stages in the process is – there’s actually more than one interview. Some of it’s just tests, but there are also interviews, and in those interviews we’re paying attention, you know, do they really want to work for Made Tech? Are they interested in what we do? But we’re also trying very hard to make it fair, so we interview in pairs, we have more than one style of interview – we have face-to-face interviews, we have phone interviews, we have pairing interviews – so we’re trying to give people as much chance as possible to showcase their strengths.
Another principle that we’re following is that we are aware of diversity in all its forms, but one, and a really important part of that, is being aware of neurodiversity. So for instance, there’s actually slightly higher proportion of people in our industry that have some forms of neurodiversity. So we’re aware of ADHD, dyslexia, people who are on the autistic spectrum, and we try to make things as comfortable as possible and be aware of the way in which neurodiversity can impact people. So we will ask whether they have any visible or non-visible disabilities, we’ll give them a chance to tell us about that, and for us to make any adjustments that we need to make. We don’t give time limits for coding exercises. We actually allow people to do it in their own time. That can really help people who have particular challenges. We try to make sure that people are very well informed. That can also be helpful to some people.
The final principle for recruitment is that we get the whole company involved. So it’s not just a small group of people, we get people from Made Tech involved in reviewing coding tests, in doing pairing interviews, in doing face-to-face interviews. We have what we call introduction days, which are incredibly valuable actually. That comes right at the end of the process, where a small number of people will be invited to an introduction day, and during that day they get to meet other people from Made Tech. We have some talks from previous graduates of the academy programme, and we do pairing, where we will put interviewees in pairs with each other, and what we’re encouraging them to do is to showcase each other’s strengths. So what we want to see in the pairing interview is that they are helping each other to look good, and also that they are able to collaborate and generally help one another and nurture one another. The introduction days are great, they’re almost like a mini conference, so everybody gets to meet each other. When it’s physical we all eat together. When it’s online we simply give them an opportunity to log in at lunchtime and at breakfast time, although we do give them space to go away from their computers as well, that’s quite important. We want it to feel like a community event, and people generally say that they really enjoy those introduction days, even though obviously they’re quite scary because there’s a significant interviewing element as part of that, but we also want it to be enjoyable for them.
So, that’s getting ready for the academy. What happens during the academy? So, once we’ve selected our final people, and for the next academy it will be 16 people, again there are a few principles that we try to follow. The first one is that we want to nurture these people, and there are lots of things that we do in order to facilitate that. So we make sure that they have regular breaks. We don’t want them to spend all their time in front of their screen. We don’t want them to get exhausted. It’s quite full-on, particularly because we’re doing everything online at the moment. We keep sessions short and we make sure that we schedule lots of breaks during the day. We also make sure that people are following reasonable working hours, so we don’t give them any mandated work outside of working hours. I mean, they will end up doing work outside of working hours but that is entirely optional, and it’s not something that we that we encourage even. Really we’re not going to stop people from doing it, but we really want them to have reasonable working hours, we want them to be well-rested. We want them to think of it as a job but we also want it to be fun, and that’s that like… I know that some people don’t like the idea of mandated fun or ‘official’ fun, but we do make a point of putting time aside to just chat. We have coffee breaks every morning. We deliberately play games at the start of many of our sessions. We want people to be relaxed, and we also want them to get to know one another. We want them to bond with each other. We want them to be helping each other and learning together. So it’s really important that we give people opportunities to get to know each other and be able to relax in each other’s company. I’ve mentioned it before, but at the start of every day we have a daily… we call it a ‘stand-up’. Really it’s just a chance to have a bit of a chat and just kind of warm up, get to know each other, ready for the day ahead.
So another principle that we follow is that we try to be respectful towards our engineers and encourage them to be respectful towards each other, and obviously towards us. We try to also be empathetic towards them, try to think about things from their point of view. So one of the things that – this is a general principle that I follow in all areas of my life, particularly in this industry – is that I encourage people to ask simple questions. I mean any questions, but simple questions are fine. There’s no such thing as a stupid question. Keep asking questions all the time and keep answering questions. I will deliberately ask simple questions myself, and they’re real questions. What I’m trying to show is that I also have gaps in my knowledge and I’m not afraid of looking stupid. I don’t mind if people know that there are gaps in my knowledge, and I’m trying to model that behaviour. I want them to feel confident about asking any question that they want to ask. It’s also really important that we listen to them, so we don’t want it to be a passive experience. We don’t want it just to be about us telling them stuff and them absorbing it. We want them to be able to tell us stuff. Sometimes they can teach us things that they’ve learned that we didn’t know about, but also they can give us feedback on how things are going. We tend to tweak the content constantly as we go along, and tweak the organisation in response to their feedback, and part of that is trusting people. So we trust people to do the learning, we trust them to care, we trust them to help each other, we trust them to take it seriously. We don’t treat them like schoolchildren. I mean, to be honest, I have issues with the way that schoolchildren are treated anyway. I don’t think schoolchildren should be treated like schoolchildren, but I think if you’re teaching people and if you want them to learn, then you have to trust them. You have to show that you trust them, that that you believe that they can do it, and that they will do. We really try to make sure that we celebrate and acknowledge and make space for people’s cultural differences. We think that the best teams are those that are diverse, and we don’t want anybody to feel like their cultural differences are anything other than brilliant. So yes, we very much try to celebrate diversity and really show that we care about people as individuals. We have regular one-to-ones, so everybody in the academy gets one session per week as a one-to-one with myself or Charlene or other people from MedTech who are helping out with the academy, so that they get a chance to just have a chat- again, to let us know how they’re doing, to talk about what they need to focus on and to just give them a touchpoint, and again make sure that they know that we care about them, that we’re listening to them, that we want them to be okay.
And then they… not all of the teaching sessions are with a teacher and with learners. So a lot of the time they’re learning in pairs or they’re learning in groups or they’re doing activities, and we try to drop in on those activities, drop in on pairs, let them know that we’re paying attention to them, that we care about them and that we’re listening to how things are going. So a really important part of the way that we do software development at Made Tech is collaboration. We very much care about this, so therefore it makes sense that we want our teaching and learning to be collaborative, and that we’re teaching them – collaboration. There are lots of different ways in which we do this during the project, so this is something that I do with teams when I’m being a technical lead on software teams, it’s something that I also encourage the engineers to do in the second half of the academy: they all collaborate together to produce an end-product, and during that time I encourage them to have regular ‘tech time’ which is something where teams get together and talk to each other about challenges they’re facing, about new technologies that they’ve learned, problems that they’ve solved, so that they can showcase to each other things that will be useful to each other, and that’s a really important part of collaboration.
We also have regular retrospectives, so very regular. We have weekly retrospectives at the end of every week of the academy, but we also frequently have daily retrospectives, where at the end of the day we look back over what’s happened that day and we talk about what went well, what didn’t go so well, what we could improve on. And we’re very much encouraging them to be a part of thinking about how they learn and how the academy is delivered, and that’s a very important collaborative principle. It’s a really useful skill to build good collaborative teams. We’re also teaching them how to facilitate retrospectives, so we encourage them to facilitate our academy retrospectives, and we also encourage them to facilitate retrospectives when they move out of the academy and start working with our clients during the sessions. So quite often, typically a session will last about an hour and a half with breaks, but it won’t typically be particularly like last the last academy. We had 12 engineers; the next one there will be 16 of them. What we don’t want is for there to be 16 people all just sitting looking at a screen and being talked at, so – and it’s actually quite difficult, it would be difficult in a room, I think it’s particularly difficult online to get 16 people to all have a discussion all at once in the same space – and it’s also particularly difficult for people who are a bit nervous and who are still building their confidence. Because we’re taking people who are very inexperienced, that’s something we have to be very aware of. Some people are more confident than others, and what we don’t want is for the people who are less confident to just get drowned out or to just kind of get lost at the back of a room, so to speak.
So what we do is we use Zoom (there are other technologies are available) but we move people into breakout rooms frequently during our sessions so that they can work together in smaller groups, so that people can have a voice, and so that they can be heard, and so that they can be actively participating in what we’re doing. We also use ‘mobbing’ which is known also as mob programming. It’s the idea that you get a group of people together to all work on one problem at the same time. So there is a shared screen, there’s a shared piece of code and everybody is working on it together, which is a fantastic way of building collaboration. We also use pair programming. So mob programming is kind of an extension of pair programming. Pair programming is something we use a lot as an organisation, and we use it a lot during the academy. It’s a fantastic way to learn, you’ll often find in software teams because pair programming is not a ubiquitous practice throughout the profession; it gets used kind of here and there, and you’ll quite often find that in teams where it’s not used for everything, the one thing it is likely to be used for is learning. When one engineer needs to learn something then they will pair with another engineer, and they’ll work together on the same piece of code. We do that a lot in the academy. By ‘ad-hoc pairs’ what I mean is that we will put together pairs at a moment’s notice to work on one small problem or to learn one small thing, but we also use ‘long-term pairs’ where we will put people in pairs and they will work together for a few weeks on one particular piece of code, which means that they get to really get their teeth into it, they get to build up a good relationship with each other and they get to really get that experience of what it feels like to be able to build up a kind of long-term collaboration with another engineer.
As well as being collaborative we want to be interactive, and I’ve already actually made reference to this several times. We don’t want people to be passive learners, it’s not an effective way of learning. So I’ve already mentioned that we have frequent retrospectives that people can participate in, and we do also give people time to go away and learn on their own, but we still want that to be interactive. We want to be hearing about what they’re doing. We want them to have some input into how that happens. And again, the fact that when they do personal learning we actually give them exercises that they can interact with, so that they are active learners. And again, it’s they’re not just passively consuming content. We do have a mix of lots of different session styles, so sometimes there will be a kind of lecture format – we try to not to have too many of those because they’re exhausting and they’re not necessarily the most effective way to learn – but there are some lecture format sessions. We also have workshops, we have pairing, we have mobbing, we have games at the start of sessions. We try to find lots of different ways for people to interact. We have showcases, so this is where we encourage people to do a little presentation to showcase what they’ve learned or what they’ve built, and we have those every week. We encourage everybody to deliver at least one showcase. They generally have an opportunity to deliver several showcases, and we do pay attention to who’s delivered them as well. So we try to get an even spread. Again, we want that to be a highly interactive process, and it’s not just about what they’ve learned during the academy either, so people can do a showcase on knitting patterns, or anything that they happen to be interested in and that would be interesting to the rest of the group.
We use a technique that I call ‘learn to teach’ and or ‘learn by teaching’ – actually it’s more like ‘teach to learn’ but anyway… so the idea is that we encourage our engineers to go away and to learn on particular topics, or learn particular technologies, and then teach it to one another. This is a technique that I use myself a lot, that I find – and this is partly why I enjoy teaching – it’s partly selfish, I enjoy helping people but I also find that whenever I teach something I deepen my own knowledge, and I consolidate my own knowledge. Like for instance, there was one time at a previous company that I was working at, that somebody advertised a Clojure bridge workshop. So this was teaching Clojure to people who had never used it before. Clojure’s a functional programming language, you might not have heard of it, it’s not actually that common, and I’d never, but quite a lot of people in this company do use Clojure and I didn’t know it at all I’d never used it. They were advertising this workshop for beginners, and they were asking for volunteers, and I thought… I volunteered to teach a workshop, despite the fact that I didn’t know Clojure. And what I did have was years of programming experience. It’s a lot easier when you have that, so what I did was I simply spent a day going through the syllabus the day before, and that gave me just enough that I could teach other people. But in the process of teaching other people, I consolidated that knowledge. It’s a fantastic way of consolidating what you’ve learned, so we also encourage our engineers to do that.
I’ve written ‘polymorphism threes’ here. I’m not expecting you to know what that means! Polymorphism is one of the topics that we teach. Again, you don’t need to know what that is, but the reason I’ve written ‘polymorphism threes’ is that this was something that the engineers themselves came up with in our last academy. They had learnt polymorphism and it hadn’t really worked. They were all mostly… nearly all of them were quite confused about it, and so what we did was they spent a little bit more time refreshing their knowledge and then they got together in groups of three to talk to each other about what they found confusing, and to work together to make sense of it. And by mixing together the bits of it that each one of three people had managed to understand, between them they came to a much stronger understanding, and that that was a really nice way actually of interacting and creating learning as a result.
Another principle that we follow is that we try to… I mean, we do put a lot of effort into teaching soft skills. That’s ‘soft’ with inverted commas. I’ve written it like that because I don’t really like the phrase ‘soft skills’ because it suggests that they’re less important. And generally what people mean by soft skills is ‘people skills’ – and so being able to communicate, being able to collaborate and being able to do all of the things that are absolutely crucial if you’re going to have effective teams and if you’re going to build effective software. Building software is not something you can easily do alone – you have to coordinate with one another – and all of the skills that involve coordinating effectively with other people are what tend to be called soft skills, but they’re absolutely crucial.
So some of the things that we do to teach those skills, one of the things that we do is we pay attention from the start to engineers that tend to dominate, and engineers that tend to take a back seat, and then what we do is we spend time one-to-one with those people. For the people that tend to dominate, what we’re doing is teaching them to be aware of that, and then we’re teaching them to also pay attention to the people who are less active and to try and be allies to those people. So to try and put themselves on a back burner and use the skills that they have and the confidence they have to help other people to come out of their shells. And then with the people who are less confident or just quieter, we want them to be taking an active part. Obviously we’re not going to force them to be extroverts, but we do want them to be active. We want them to be visible, and so we talk to them, we help them to build their confidence and build their skills, for instance to be able to present information to a client. As well as trying to be empathetic towards our engineers, we encourage them to be empathetic towards each other and to understand how important it is to be empathetic towards everybody that they work with – towards our clients, towards their colleagues – and we put a lot of attention on that. I’ve already spoken about collaboration, but it’s a really important soft skill, and communication – so, you know, written communication, oral communication, making sure that they can make themselves understood and they can explain things to a variety of different skills and audiences.
We also encourage them to mentor one another, as they will be when they move on to our client projects, they will be mentoring and being mentored by their colleagues and also our clients, so that’s a very important skill that we want to help them build. And I think underpinning all of this is the fact that we put a strong emphasis on having a strong feedback culture throughout the whole company, but particularly in the academy, because we kind of have a captive audience there. We can put a lot of emphasis on feedback culture, and then that helps them to be ambassadors for a feedback culture and take it out into the rest of the company and into our clients. When I say feedback culture, what I mean is that we want everybody – and that includes us – to be constantly asking for feedback and giving feedback. So whenever we’re talking to them about skills that they need to improve – we talked about how they can use feedback to move forward in that, how they can ask one another for feedback about how they’re doing, and ask us for feedback and give us feedback as well about how we’re doing – how we’re doing as teachers, how we’re doing in coordinating the academy. And we want that to be something that happens constantly. It’s not a once a quarter or whenever you have a review, it’s all the time, asking for feedback in order to help yourself improve, and giving people feedback in order to help them improve.
We’re also teaching leadership skills, because we are in the business of consultancy. We’re helping our clients to improve their software development and we want our engineers to be able to take the lead when appropriate. So we teach them how to facilitate sessions. I’ve already talked about encouraging them to facilitate retros, but we also ask them to facilitate showcases, and any sessions that we have, we encourage them to get involved in facilitating. So I’ve just mentioned showcases – we ask them to present showcases. We talk to them about how to interact with clients. We set up a kind of fake fictional project scenario at the end of the academy where we have pretend clients, but we also just generally talk to them about what’s involved in interacting with clients.
We put a high emphasis as an organisation on user research, so, you know, the users really matter. When we deliver software, the only way that we know whether we’re delivering value is by knowing whether we are delivering value to our users, and whether we are giving the users what they need and want, whether what we think works is what our users think works. So we talk to them a lot about user research and placing the users at the centre of everything they do. We also teach them some project management skills. So again, I’ve mentioned it, I’ll talk about it in a little bit more detail later, but at the end of the academy we spend a good chunk of time giving them projects to complete in teams, and they do their own project management. They don’t have project managers for that section so they have to do their own project management. So we teach them a little bit about Agile project management and encourage them to take ownership of that. And generally again as an organisation we use Agile methodologies, so we teach our academy engineers – a lot of them know about it already – but we teach them about all of the different Agile ceremonies and we bring those into the academy. So, stand-ups in the morning, retros regularly, we talk to them about planning and we talk to them about estimation, we talk to them about backlogs. So we talk to them about how to do Agile project management, and we are also delegating to them. So we’re encouraging them to take control and take ownership for what they’re doing, rather than us always being in charge, so to speak.
Another thing that we really care about is making things concrete. So we help them to prepare for the future, we talk to them about what’s going to happen after the academy when they really are building software with our clients, and we have an off-boarding section where we put a lot of effort into preparing them for what comes next. We show them some real code during the academy. I say ‘real’ – I mean it’s all real, but we show them the code that’s actually out there in the world, and with the permission of our clients we show them codebases that we’re working on with our clients.
And we’re talking about psychological safety. When you’re working in teams, sometimes you can find yourself in environments where people are not collaborating well, and where people don’t feel psychologically safe. So for instance, if there’s a high blame culture or if people feel that they’re not able to be honest or transparent about things that are going on. they don’t feel able to ask simple questions, they feel judged – We’re talking about what that feels like, about how to identify it, about how to address it when they come across it, because unfortunately we don’t live in a perfect world and we don’t want to pretend that we do. So we make it very clear that psychological safety matters, how to look out for it and how to try and help it to happen.
And I’ve mentioned diversity and inclusion, but we talk to them about diversity, we talk about paying attention to people in underrepresented groups, about being aware of the fact that unfortunately our industry isn’t as diverse as it could be, and how to be aware of that, how to make sure that you’re being inclusive of all of your colleagues. And I’ve mentioned it in several contexts, but we want to get everybody involved in our academy. It’s a really important part of it. So we have clinics where we encourage other engineers within the company to be available as we call them ‘clinicians’ – It basically means that they set some time aside and they’re available for people to come to them with any questions or problems that they have, and that’s a great way of getting other people in the company involved. And people love being involved, in the company. I mean, I was going to mention it at the start actually, but I largely joined Made Tech because of the academy. It was a big attractor for me. People love having it, you know. Everybody wants to get involved. It’s a big… it’s a very important part of Made Tech that people really care about.
We encourage our other engineers to review the code of our academy engineers. We encourage everybody to get involved in academy Slack channels, and we encourage Slack channels as the communication medium that we use for everybody to chat together within our company. We also encourage our academy engineers to go out and join all of the other Slack channels in the rest of the company. We bring in other people, not just engineers, from the rest of the company to talk about their careers. We try to have a really diverse range, so we have people who don’t have degrees for instance, who’ve followed non-traditional routes through their careers, we try to have a really broad range of people who’ve followed different career paths, just to show that there isn’t only one way of doing it, and we also we encourage our engineers to do showcases to the rest of the company, and also our engineers attend showcases that are presented by other people from the company. We also get other people involved in the company in doing presentations and delivering workshops to our academy engineers, and we have a one-day academy conference that we ask everybody in the company to get involved with. We also we get people outside of Made Tech involved in the academy conference as well, so people from other boot-camps come along, people from our clients come along, and it’s a chance for our academy engineers to get to know other people and to showcase what they’ve been doing.
Then, I’ve mentioned it several times, but for the last five weeks we give them a fictional project. So they spend a short period of time discovering what it is that they need to build, and what the issues are, and who the users are, and what matters. We then ask them to deliver proposals as they would do in the real world to our clients, to propose how they would go about building these projects. We have fictional customers – that’s a bit hard because none of us are that great at acting! But we do our best to pretend to be clients – and then at the end of that period – so it’s a five-week period, I’ve called it the last half, and then that annoys me because I’m a mathematician and it’s five weeks out of twelve, so it’s not half, it’s five twelfths, but it’s roughly the last half of the academy – they spend a full five week project, and then at the end they showcase what they’ve built.
So, to track success: I realise I’m running out of time, so I am going to speed up a little bit at this point. Apologies for that. There is an official assessment, so we have running assessments throughout the course. We’re doing it slightly differently next time, but we’re going to continually assess them on various key skills. We also ask them to self-assess, so we ask them to keep a running tab of how they’re doing in various key areas, and we give them official targets that we want them to meet. So we use the SFIA framework to describe what is expected of an academy engineer, and in our one-to-ones we discuss all the various aspects of that framework and how they’re doing. We ask them to set themselves objectives, and then track against those objectives, and we also review the code that they are writing as part of the academy.
And then once we’re done, again, we want to get everybody involved in nurturing the engineers and supporting them through their careers as they move onwards. We encourage them to set up support groups with one another. We use the Action Learning Framework, which is worth googling, which is a really nice way of setting up support networks. We ask them to fill in questionnaires on how the academy went and how they’re doing as they move forwards throughout their careers. We pay attention, we keep track of them, we monitor their progress, we stay in touch with them. We keep communicating with their new teams and providing support for them as they move onwards in their careers.
So, to summarise: When we’re recruiting for the academy, we want to make it attractive. We want to go to them and not just wait for them to come to us. We make it multi-layered, so there are several stages in the process. We pay a strong attention to diversity and to neurodiversity. We get everybody involved.
Then, during the academy, we’re nurturing our engineers. We’re giving them regular breaks, sensible working hours, encouraging them to have fun and scaffolding that for them, having daily coffee every morning (you don’t have to drink coffee). We’re being respectful towards them. We’re encouraging them to ask questions, we’re listening to them, we’re trusting them, we’re trying to make sure that it’s inclusive, we have regular one-to-ones, and we drop in on them when they’re working independently.
We’re encouraging collaboration throughout the whole process. We want the academy itself to be highly collaborative, so we encourage them to use ‘tech time’ to share what they’ve learned with one another, we have regular retrospectives where we constantly review how we’re doing, we put them into breakout rooms rather than expecting them to always be in one big session – so that they can work in small groups and be heard and be involved in what they’re doing. We use mob programming to get everybody involved in writing code collaboratively together, and we use pair programming as well for the same reason.
We want them to be highly interactive – we want them to be really engaged in their learning, so retrospectives again facilitate that. We give them lone learning to do but we make it interactive. We use several different styles of teaching. We encourage them to showcase what they’ve learned and what they’ve built to one another. We encourage them to learn by teaching, and we also put them into groups to review what they’ve learned.
We pay attention to soft skills – so for people who are dominant, we encourage them to pay attention to other people and take a little bit of a step back; for people who are less active, we encourage them to take a step forward. We encourage them to be empathetic towards one another and towards all of their colleagues. We encourage them to collaborate strongly with one another. We encourage them to build their communication skills, to mentor one another and to be constantly giving and asking for feedback.
We’re trying to teach them leadership skills as well. So we want them to be able to facilitate sessions, to present information to our clients, to pay attention to the user experience, and to be able to do user research. We teach them project management skills. We teach them about Agile delivery, and we delegate some things to them.
We try to make things concrete. So we have an eye on the future. We have a conscious off-boarding process. We expose them to code ‘in the wild’ that is actually live with our clients. We talked about psychological safety, and we pay attention to diversity and inclusion. We try to get everybody in the company involved, so we ask people to run clinics to review code, to get involved in Slack channels, to talk to our engineers about their own careers, to deliver showcases and attend showcases, to deliver workshops and to get involved in our one-day academy conference.
And then at the end, we have a five-week project where there is a discovery phase, where they deliver proposals as to how they’re going to proceed. There is a fictional customer, and at the final end of that they are delivering showcases. Also there’s some element of assessing what they build during that time, and that goes towards the assessment as well. So on the subject of assessment, I didn’t explicitly talk about badges. I talked about the fact that we have rolling assessments, we call them badges internally, and that’s something that exists throughout Made Tech, independent of the academy. We encourage them to get involved with that, and to earn their badges. And they also do some self-assessment. We’re constantly reviewing their objectives via one-to-ones. We ask them to set themselves targets, and their code is being reviewed.
And then once it’s all done, again, we want everybody to be involved. We encourage them to create support groups, we use questionnaires to track their progress, we keep in touch with them, we keep in touch with their new teams and we continue to offer support.
Okay, that’s me… oh no, that’s not me quite done! What next? So we also help our clients to build programmes. So we have helped HMRC to build an apprenticeship programme, and we can arrange a meeting or a workshop with you to help analyse your organisation’s learning needs, and to identify whether you would also benefit from running some kind of academy programme, which we can run for you or help you to set up.
Jack: Okay, Q&A! Lovely stuff, thank you very much Clare. First of all, thank you wonderful talk, as always. First question is: “What do you think is the upper limit of how many people you can have in the class – as you are adding more?”
Clare: That’s a really good question. I think 16 will probably be the upper limit, and it’ll be interesting to see how it goes actually. 12 worked really well. I think we’ll be able to do 16. I think more than 16 would be a challenge, but obviously what the thing is, that what you do is, the more people you have involved, the more use you make of smaller sessions, the more you break people up into smaller groups in order to do things, and you try to minimise the amount of time you have where everybody is just all together in a room. We have talked about having an academy where there will be 20 engineers, but the extra four will be part of a separate track. So we will have possibly a user research track or possibly a project management track, and that would be… a lot of the time they would be spending in separate sessions, they wouldn’t be doing the same sessions as the as the main engineers.
Jack: Lovely, next question: “Have you had situations where people have felt less psychologically safe while in the academy, and how have you handled that?”
Clare: Yes absolutely. There have been times, I mean I’ve kind of alluded to it, because I mean luckily we haven’t had anything terrible happen. When I say terrible, you know, for instance we haven’t suffered from anybody like being severely prejudiced against one another or bullying one another, and if we did we would take that extremely seriously. We wouldn’t allow that to continue. But then again, you know, the screening process, we’re very much looking for people who are empathetic, who care about one another, who are collaborative. So I hope that we would spot that. We would not bring people onto the academy who might display those behaviours. But of course, you can never know.
But what we have had is people feeling side-lined and people feeling talked over or talked down to, and because we have such a strong feedback culture, because we have so many one-to-ones, because we talk so much about empathy and we’re paying attention to encouraging people to look after one another, I like to think that we’re very open as well. I like to think that we’ve created an environment where people feel that they can talk about those things, and we’ve been able to approach people and give them feedback and let them know when they have been in situations where they’ve dominated or when they’ve made somebody else feel uncomfortable. It’s something we address instantly. We talk to people, we don’t want to let those things slide, we talk to people if we feel like they’ve created a problem for somebody else, and we also encourage people to be able to talk about it if they’re experiencing problems.
Jack: Lovely, so the next question is a bit of a follow-up: “Similarly have you had people in the academy who have struggled to keep up with the work, and how has this been managed?”
Clare: Yes, that has definitely happened, and it’s not just that people have struggled to keep up with the work, it’s that they felt like they were struggling to keep up with the work because one of the problems that a lot of our engineers suffer from is because we have such a diverse range of people, inevitably some of the people on the academy are more experienced than others. Some of them are older than others, some of them have degrees, some of them don’t, and it’s quite common to see the people who don’t have degrees feeling insecure about the fact that they don’t have degrees, or the people who are younger feeling insecure about that, or people who have never had a job in their whole lives because they’re so young and they’ve come straight out of university for instance. It’s studying another subject, and then they worry that all of these people around them are all really experienced, and I’ve had loads of different jobs and worked in other industries. It happens, and then they worry, they think “Oh God, everybody I’m working with knows so much more than me.”- and so one of the things that we really encourage them to do is to really use the pairing sessions to pay attention to each other, to help each other when each other is struggling, but also to notice when the person they’re pairing with is struggling, because if you pay attention you’ll see that everybody struggles with something. And it’s one of the big values of pairing, is that you get to see that “oh, they’re googling everything too, it’s not just me!” and so part of it is about changing their perception and making them realise it’s just that everybody’s different, and everybody moves at a different pace, and everybody knows different things and learns different things at different speeds.
We also, although we do use assessment, we are also very clear that we don’t expect everybody to pop out at the other end of the academy being identical or even knowing the same things. There will still be disparity in knowledge, and that’s okay. They don’t have to know everything, and one of the things that I constantly reiterate is you will never know everything. You don’t have to, but you can’t, and you have to make your peace with that. This industry is too big to fit in any one person’s head. It’s literally impossible, so don’t aim for it. Accept it, accept that throughout your career you will be learning, and throughout your career you will have knowledge gaps, and that is okay.
So a part of it is all about that, but also we will sometimes set up one-to-one sessions with people who are struggling. I’ll spend extra time with people to help them. I’ll point them at extra resources, but what I don’t want is for people to be working extra hours. They will learn as much as they can learn in the time that is available. I trust them to do their best. I can’t ask any more than that.
Jack: Lovely, next question was: “What was the name of the framework you used to assess the skills and behaviours you expect from an academy engineer?”
Clare: Oh good question, yes it’s SFIA. I can’t remember what it stands for, but if you google it there’s tons of tons of stuff about it.
Jack: Outstanding. Next question: “Does your curriculum of technical skills during the academy focus on a particular language, and what kind of wider software engineering skills do you cover?”
Clare: Yeah, good question, and I didn’t have time to put in a slide on that, but for the first seven weeks we focus on Ruby. it’s a good teaching language because it’s you can get up and running very quickly with Ruby. You can create something that works within minutes, but it’s also object-oriented which… a lot of languages that we work within are object-oriented, so you can teach what we call SOLID which is one of the things that we focus on. I’ll have to ask you to look that up, I’m not going to try and describe what SOLID means, because it’s a bit in-depth. But we teach object-oriented programming, we teach SOLID, we use Ruby as our language. We teach test-driven development, we teach pair programming, we teach all of the things that are associated with SOLID and object-oriented. So I mentioned polymorphism before. We teach Agile delivery techniques, we teach all of the soft skills that I talked about, we talk about… we teach Git, we teach command line stuff, we teach how to use source control using Git, we talk about continuous delivery and continuous integration.
We also talk teach them how to deploy code. The last five weeks are really crucial for that actually, so in the last five weeks they are actually deploying code. They’re learning about pipelines and deployment. They also learn about databases and integration and testing and all of the different ways you can test. We teach front-end development, so they also build web projects, both in the first seven weeks and also in the last five weeks. I’ve probably missed stuff out, but I mean we do cover a lot. We do cover a lot. We cover broad principles and we cover in-depth principles. And we kind of really try to make it clear that it’s – although we’re using Ruby – these principles apply to lots of different languages. And in the last five weeks we move away from Ruby. So in the first seven weeks we use Ruby as our language and Sinatra as a simple front-end framework that you can build web apps using Ruby with.
In the last five weeks we completely switch it up. we change technologies totally, but I’m not going to tell you what, because we actually ask them to learn those technologies themselves, and part of the point of it is to say you can learn any language now, and you will have to during your career. And that’s okay, don’t be scared of it! Once you understand the principles, you can learn new technologies and you can learn new languages, and it’s not the language that’s important, it’s the principles.
Jack: Lovely. Well I’m afraid that’s all the time we have for our Q&A. I’m just going to share my screen again, and I’d just like to start off by saying a massive thank you to all of our attendees for coming today, and an even bigger thank you for Clare for speaking. It’s absolutely wonderful. As I mentioned at the start of the session, we will be sending out feedback forms to all of our attendees. If you have time, they only take a minute to fill out and they really help us out to improving our webinars.
As I also said, there was a little bit of a mention of what’s coming up next for Made Tech. Next week, on the 2nd of March, our Market Principal in London, Bristol and Wales – Tom Taylor, will be speaking alongside Rox Heaton, Director at GDS; Sally Meacham as CEO at Welsh Centre for Digital Government; Jenny Syme, the Programme Manager for Digital Offices of Scotland and Local Government. He’ll be speaking on the Supporting COVID Recovery panel at the third Public Sector Innovations Conference with digital leaders later on in the week. On Thursday, we’ll have a talk from our very own Glen Ocsko, Head of Local Government here at Made Tech, on “Why evolution is the new transformation” This is with the Insights Live Public Sector event, also with digital leaders.
And also very exciting, we have the Making Tech Better podcast, also hosted by the wonderful Clare Sudbery, coming at the beginning of April. Clare, do you have 30 seconds to quickly plug that?
Clare: I’m so excited about this! Yes, we think it’s April, probably in April, we are going to be launching the Making Tech Better podcast, which we will actually launch with several episodes at once. We’re busy making those episodes now, and then after that we will be putting out fortnightly podcasts on the topic of improving software delivery.
Jack: Brilliant, thank you Clare. So yeah, if your question didn’t get answered by Clare during the Q&A, please do reach out. Her Twitter handle is up on the screen: @claresudbery. Information about all of our upcoming events, we’ll be posting on our social media channels, which are posted on the screen. Or if you just want to stay up to date with all things Made Tech, please do get in touch. We’re very open, and we love it when people reach out. And with that, I once again say a massive thank you to Clare and to all of our attendees for coming by this afternoon. Have a great day. Bye.
[recording ends]
Back to the episode
