How to leverage continuous learning to deliver better services

Open the transcript in a new tab

Jack: Good afternoon everybody and welcome to our ‘Made Tech Talks’ webinar. Today’s topic is ‘How to leverage continuous learning to deliver better services’. Our speaker today is our very own Toby Maritz, one of our Senior Engineers here at Made Tech.

Before I hand over to Toby, I’m just going to very quickly run down how today’s going to go:  So once we’re done with housekeeping from me, I’m going to hand over to Toby for a 45-minute presentation, followed by a 15-minute Q&A at the end. So if you do have any questions for Toby throughout the presentation, please make sure to add them to the Q&A function found in your toolbar, or just throw them in the chat. Once the webinar has concluded we will be sending out feedback forms to all of our attendees. They take about a minute or so to fill out, and they go a very long way to helping us improve our events for the future. We’ll also be sharing a little bit of information on what else we’ve been releasing recently from Made Tech, so stick around at the end to find out more about that.

Now I should mention this presentation does come with live subtitles, so if you’d like to access those please press the ‘cc’ icon down at the bottom of your screens. Information on how to access these will be posted in the chat throughout the presentation just in case you missed them on the way in.  Last note from me: This session will be being recorded. And that’s everything from me, so I’ll hand over to Toby. Toby, do you want to take it away?

Toby: Thank you very much Jack. So as you mentioned, my name is Toby Maritz, a Senior Engineer here at Made Tech, and today I’m going to be talking about leveraging continuous learning to deliver better services.

So firstly we’re going to talk about learning: What is learning? What does it mean? What’s continuous learning? Next we’re going to talk about services, so what do I mean by services?  In my world it means – it could mean something very different from what you perceive as a service.  We’ll talk about some of the pitfalls and considerations when learning and when trying to tie these two concepts together. We’re then going to take you through a short thought experiment. I’m a bit of a techie at heart so it’ll have a technical flavour, but don’t worry, it’ll be very high level and you’ll be able to understand it. Lastly we’ll go through some examples of how you can get started applying some of these learning activities to your teams.

So the first thing: ‘Learning and services’. What do I mean by learning? Well I quite like this quote or this definition: “The acquisition of knowledge or skills through study, experience or being taught” – and the key there is that it’s knowledge and skills, and it’s experience as well as being taught. So it could come from many different avenues in many different forms. It occurs when we gain a mental or physical grasp of a subject. We make sense of a subject and we interpret it into our own words or actions.

When you think about learning, what’s actually happening is this cycle. So you procure some new knowledge of a theory, an ability or skill; You then apply it so that new knowledge or skill is then practised in some way; You then consider it – so this is a period of reflection; You practise it, and you evaluate whether or not it was successful. And then your initial knowledge and your initial self is transformed by that learning activity. So you’re then a greater person, or you have a greater wealth of experience.

Now the key here is that you need to be engaged in that learning activity. If we don’t have the will to learn, then we won’t learn, will we?  And if we do learn, then we’ll be changed in some way. And part of this is the relevance of your learning activity. If the learning makes no difference to what to your passions or your interests are, then it can have very little significance beyond being random ideas that float through your consciousness.

So let’s talk about the goals. The goals in learning are to be engaged – it needs to be an engaged learning activity. Next we want that learning activity to form the default approach to solving problems – so we want learning itself to be the default approach to solving problems. So as an obstacle arises, we want to think about how we can learn from it rather than, you know, throwing up our hands and asking someone to do it for us. We need to think that it’s something that we can learn from, and that we can grow as a person and share that knowledge, and hopefully be able to overcome the obstacle in the future with much more ease.

So what do I mean by ‘continuous learning’? Well, it’s the process of learning new skills and knowledge on an ongoing basis, and it can come in many forms – from formal course-taking to casual social learning – but it does involve the self-initiative and desire to take on these challenges. It’s all about having this growth mindset, and what’s actually happening is you’re building your own knowledge, you’re sharing it, and you’re then rebuilding that initial wealth of knowledge. So this is the key to continuous learning, that we want to continuously grow and continuously upskill.

So what do I mean by ‘services’? Well, it’s anything and everything really. Like I said, my definition is probably vastly different from yours! At Made Tech, here, we predominantly work with the public sector – so the NHS, the Ministry of Justice, the Department of Education, the DVLA (which is where I am at the moment) and the HMRC – so for us it’s normally a technical consultant software-based outcome that we’re looking for here.  I’m a software engineer so I’ll be I’ll be coding all day to produce an application of sorts, and that would be what I define as a service. But it’s certainly not limited to tech, so a service can be recruitment or marketing or sales… it could be anything that you come into work or do to pass your time and then produce something out of it. This is what we mean by a service, and this is why I truly believe that what I’m going to go into here is applicable to any teams. Although I talk about it in a sometimes technical way, I’m going to take it from a really high level approach and simplify it and draw out those nuggets, those benefits that we draw from, these processes, and apply that to learning.

So how are these connected? When I talk about learning and services, well, it’s really about the journey. You’ve got your team, or you’re inside a team, and you should be well aware that a highly skilled, engaged team delivers a better end product or service, which then translates into a happy customer, right? And you’ve got to think about that journey. So things don’t just happen, you don’t just magically produce a service. It’s all about the journey that team takes in order to produce it. So I like to think of it in this sort of upward spiral, and if we tie into learning, what’s really happening at the foundation here? So it starts with some sharing of knowledge about maybe a concept that’s going to form, and then we build that knowledge, we think about that concept and we flesh it out. We then have a good feeling of personal success within your team. You’ll feel adequately equipped to take on a challenge. We have happier teams: If a team full of people are feeling that they’re well equipped to take on the challenges of their of their job and their role, then they’ll be happy, right? Then you’ll find that problems and obstacles that appear are tackled quickly and efficiently because they’re well equipped to take on these challenges. You have a strong element of work satisfaction, so a great deal of satisfaction from knowing you’ve done a good day’s work and you’ve produced something of value at the end of it. And lastly is the service – now I say ‘customer satisfaction’ here because I believe the customer should be the end goal here – but if we have a happy customer, we inevitably have a good well-built service or a service that’s running as we intended, or as the customer intended.

Right, cool, you’ve got this whole learning thing, you’ve got the continuous learning and you’ve got the concept of a service. Is there a problem? Well, not yet. So you may be chugging along and you’re delivering your services as normal, but I believe if you let that idea – of placing learning at the centre of your team journey – fall to the wayside, it could become a problem. It could grow, it could become a bigger thing.

So a learning strategy is important. You’ve got to think it as intrinsically entwined to the output of your team, and you’ve got to understand that correlation. I read a paper recently by halt research who summarised some findings into ‘team states’. So the state that a team could be in at any given time – and I’ll summarise them here, it’s really interesting:

So the first state a team could be in is the state of ‘Contentment’ – and it sounds good, but actually it’s more about the team is only outputting the minimum work required, they’re operating completely within their own capabilities and generally they go home happy. If you go to work and you just do the bare minimum, you’re not challenged. You might go home happy because you’ve done your job, you’ve got your paycheck, you’re happy. They often don’t seek to stretch or challenge themselves, and these people have often spent a long time in their organisation. And in terms of engagement, they may not be engaged day-to-day, but they often find that engagement outside of work. So we don’t really want this team state.

The next is the state of ‘Disengagement’ – and these teams view work as mundane. They perhaps complain that they’re victims of a system that is in some way defective. There’s maybe an element of distrust, and perhaps some leaders are playing favourites, or maybe team members are playing favourites. It’s a little bit dysfunctional, so we want to avoid a state of disengagement.

The next is ‘Pseudo-Engagement’. Now on the surface everything looks good, everything looks rosy, but really what the team are doing, they’re playing the system to serve their own needs. They’re maybe placing a positive spin on reality. What you may find is that the leader is maybe more interested in their own progression than in their peers, and in their team members. You may find some engagement individually, but there’s no common direction. You know they’re all tugging in different directions to achieve their own goals rather than the team’s goals.

And lastly this is what we want, we want an engaged team. So we want the state of ‘Engagement’. We want proactive solution-focused team members, working in a positive atmosphere. We want supportive team members, professionally and personally. We want them to be trusted, trusting each other, stretched, empowered. The key thing here is that they view diversity of opinion as high value – they view conflict and discussion as healthy, and disagreements would be a source of learning. So this is what we want to aim towards.

So how do we tackle this? How do we look at this engaged team, and how do we try to improve other teams that maybe aren’t quite in that state? Well, the most important factors in one of these high-performing teams boils down to generally three things:

The work needs to be challenging and varied. We need to be setting that bar ever so slightly higher than their current skill level so they’re constantly challenged, constantly getting that satisfaction of overcoming an obstacle that they may have thought unobtainable.

There needs to be trust in there. There needs to be an element of autonomy, so the team members need to be trusted by the organisation and by each other. And I’ll talk about a few things that we can do to encourage that trust within your teams.

Next there need to be clear goals. So it’s not just leadership – that’s incredibly important, your leadership need to give clear guidance, goals about what the expectations are within the team – but it could also be through project definition, through processes put in place.

So if we bear these in mind, I’m going to talk about some ingredients that we can throw into the mix from a learning lens. These sound quite general, but from a learning lens let’s think about this:

Diverse thoughts: We want to introduce maybe an element of churn, so think about perhaps rotating team members. A team that stays together for a long time – yes it becomes incredibly effective – but you lack that different differing perspective, so think about sensibly maybe rotating team members within similar teams. You encourage some cross-pollination there. You could perhaps bring in other teams, do sort of mini secondments where another team in a different field or another person in a different field joins that team and provides their view. This is particularly valuable when they’re in close proximity, organisationally speaking, so they can see what it’s like to work on the other side of the fence.

There need to be new challenges: So again, in the lens of learning, we want to allow a learning activity to have a varied library of content. We don’t want to be bound by a specific topic of knowledge transfer. And what this means is you have a team with a broader skillset, and you want to engage with your teams to share their knowledge.

Foster distributed leadership: Now what I mean here is – this is back to the trust. So we want to give our team members the autonomy to learn at their own pace and in their area of interest. Don’t leave it to your managers to enforce a certain course or whatever; let your team think about what’s right for them – the individual – and what’s right for their team.

Feedback: Now this is a huge thing, something that we could talk for another hour or two on! At Made Tech, we’re really strong believers in a feedback culture and this means that we foster a trust-based team system.  I know that after this webinar, after any day at work, I can reach out to one of my peers and they’ll give me constructive (hopefully constructive) feedback on my strengths, maybe my weaknesses, and I can grow as a person. Feedback is incredibly valuable, and I’ll talk about it more a little bit later.

And lastly, celebrating success: Always celebrate success! Shout about all the achievements that the team has made, and make it public if they’re comfortable with that. Put a tool-set in place that allows you to do this – whether it be something like Teams or Slack – where you can, in a public channel, say to everyone “X has achieved this.”  So it’s important to celebrate success.

What I find is that when we do these things, we end up nudging our team towards that more engaged team, that highly productive, skilled, proactive team.

Great, cool, so we’ve got learning, we’ve got continuous learning, we’ve got services and we’ve got the idea of what a highly functioning team versus a not so highly functioning team looks like.  So let’s put that to one side, and let’s think about this in another way.

So what I’m going to do now is talk about a process in software development called continuous integration. Now what does that really mean? It sounds a bit like a buzzword. What it is, it’s a way for us to develop our code… (before I get started too much, this isn’t going to be technical in any way! There may be some words around that are a bit techy-focused, but I’m going to explain it very thoroughly. This is entirely for the purposes of setting the scene. I’m going to use it as an analogy for learning later on.) …so, as a developer, we sit at our computers, develop code and then at some point, because we’re all a team, we want to merge that code with the main repository. Now, how are we going to do that without breaking everything? – which can happen! – well, we have the single continuous integration and it generally falls down into four set steps in a cycle. I’ll go through them now:

First we plan: So admittedly the plan can be stretched out into other phases of this coding process, but really it boils down to estimating that work that you’re going to do. We like to think in terms of complexity – you can do it in time – so we think about how complex that piece of work is going to be before we assign a time to it.

We refine it: So, make sure that the work we’re going to do is accurate and that we can achieve it. Are there any unanswered questions? Are there any blockers that are stopping us from doing this work? We need to set expectations, so we need to say that “my skills aren’t adequate for this task, I need to call x to help me on this” – and I like to put in the SMART goals, because they’re always good to bear in mind.

So, specific – we’ve been through this – we want to make sure that it’s accurate, we’ve got a good set of requirements that we can work towards; Measurable – so we start to think of how we’re going to know that the product we come up with at the end meets what we initially set out to. So we’re probably going to talk about testing here, making sure that it is actually measurable, and it’s testable; Achievable – again, is my skill set correct for this task at hand? Do we need to wait for anything before we can actually do it?; Relevant – so there’s no good us creating a feature for an application that is only destined for six months’ time, and then in three months’ time it gets canned. That’s a lot of wasted work! We like to make sure that the work we’re doing is relevant now, and that it will be visible, and we’ll get feedback on it right now. Time-bound – We like to work in sprints at the moment, two week sprints, so we like to make sure that it’ll be achievable within those two weeks, and if it’s not then we’ll chop it down until it is. We’ll make subtasks.

So we’ve got our plan for starting the work. Next we’ll do the code, we’ll do the work itself. Now, I could go into another hour’s worth of how we code and the architecture and the tech stack we’re using, but I’m going to talk about the key points that we bear in mind when we’re working:

We need to work with others to ensure success. Gone are the days of a lone software engineer on his tod, in his darkened room, coding away.  These days, we all work as part of a quite close team, and I’ll talk about it a little bit later, but pairing is a big thing. I’m always working with someone else.

Bring in expertise if needed – so recognise where the gaps are in your knowledge, and bring in that expert. We can talk, we can think about things like technical experts, maybe communities of practice, that would help out here.

Take breaks – it’s a big thing! Always comes, up every feedback session, take breaks. You can do Pomodoro style, where you do 25 minutes working, 5 minute break; 50 minutes working, 10 minute break – but be sure to factor these in as a as an integral part of your day.

Build – So this is a quick step. I won’t hover over this one for too long. This is essentially where we get all the code we’ve written, we package it up into a nice little application, and then it’s destined for testing, which is our next step. And then subsequently a candidate for release into the wide world. It’s normally automated, so it’s not really something that we think about too much after the initial setup of this process.

And lastly, testing. This is where we put that built software to test we ensure that it meets what we initially set out to do. We can also see this as a as an opportunity to gain some feedback on the work that you’ve done, and review what you’ve done too.

Cool, so we have our Plan, Code, Build, Test cycle. So what are the benefits in this? Well, we get truly better code quality. When I say code, I don’t just mean the act of typing out; I mean that main repository, that end application, is of a much higher quality, because we get that feedback quicker, we’re able to course-correct quicker, and we’re able to make a more correct product that satisfies the customer’s requirements. Our efficiency and productivity is increased again. These are all tied, so instead of going down the wrong route for two months only to get our test and feedback at the end of those two months and have to redo that work again but slightly differently, we get that within a matter of minutes, or within an hour or so. So we know this very quickly, we know if we’re doing the right job. Cost and waste are the same thing in my world, really. We’re talking about person hours or work hours, so again we want to be going down the right route. We want to be working on the correct piece of work.

And we get a great deal of satisfaction from working like this, because we get a quick turnaround, and whether what you’ve done is correct or isn’t. And this flows into personal satisfaction, but also your team as well. As I said before, it’s a hugely collaborative effort these days, so you’ll normally have a number of people working on the same piece of work, and the feeling of seeing a green build and a green test suite is pretty good, and when you see a red one it’s not so good, and that means you need to go back to the drawing board. But the key is that it’s a quick iteration. We see this in a matter of minutes, so it’s not two months wasted.

And lastly, as we talked about before, we talked about the upward spiral that we want. We have the end result of a happy customer, because what we’ve built is correct, it’s high quality, it was efficiently made, there’s less cost involved, and we have a happy team. So they’re great benefits to have.

But isn’t it super techie? It kind of is, right, I’ve talked about things like compilation and building and tech stacks and pairing, but not really. If you take it outside of tech and you break it down to its simplest form, it isn’t, and you can apply anywhere. All we’re doing is thinking about the process or the methodology of continuous improvement. We want to do lots of little things often and see that feedback quickly. So this is the key here, and this is what I want to bear in mind as we go forward.

So let’s go back to learning – we’ve talked about code long enough. So can we get these same benefits in learning? Well, I’ve just taken the same set of benefits and crossed out a couple of things that are a bit techy. We get improved service quality -so as I said, we’re improving our code quality which is that main repository, and therefore our end product. We’re improving our service quality by trying to implement a methodology like this. Our efficiency and productivity are increased. We’re not wasting time going down the wrong avenue. Cost and waste: Cost might be things – might be actual materials – but like my world, it may also just be person hours. And waste, again like I was talking about, materials, it’s the same for me but for you very well maybe physical materials. Satisfaction and teamwork, not just the engineer, anyone that’s involved in this team learning process. And again, we’re continuously learning, we’re continuously upskilling, we’re going to get a good product and a happy customer.

So let’s map these over, let’s talk about this concept: So, CI to CL (continuous integration to continuous learning).  All I’ve done there is swap out ‘code and learn’ and ‘build and apply’ – so let’s go through that process now but through a learning lens.

So let’s plan: How long will this learning activity take? I want to learn something, how long is it going to take? What do I need for it? Do I need x resource? Do I need this person available? Let’s refine it: Is it the right thing to be learning? Will it benefit me, and will it benefit my team? Let’s set some expectations: Is it realistic? There’s no good saying “I want to complete a degree in three months” – you might be able to, but it’s probably not realistic. Let’s break it down into small chunks. Like I was saying, this process happens very quickly, in a matter of minutes, so we want to break it down to as small chunks as possible.

Let’s bring back these SMART goals again: Specific – let’s ensure that we have a a pretty tight scope on what we want we want to learn in in this activity. Let’s make sure it’s measurable, so let’s be able to look back and say “yeah I did achieve what we set out to do”. Make it achievable: Can I actually give a talk on whatever it might be? So we want to make sure that we can actually achieve that that goal that we set up to do. Now, relevancy is something that I actually don’t deem as important in the in the context of learning. I believe that people should be striving towards T-shaped skill-sets. So we should be thinking about not just honing in on a single expertise, we should be thinking about broadening their knowledge and letting them see their work through another perspective. And lastly, time-bound: simply put, allocate an hour – whatever the activity is you’re going to be doing – give it a time. Things like pairing, we’re going to be thinking about timing there as well. So these are some things to bear in mind when we plan.

[Learn]: Do the thing! Do the course, do the workshop, the collaboration piece, the peer review, whatever it is. Now these are actually a few things I’m going to go into a bit later, but these are the things we want to think about when we’re learning. It’s not just courses!

Next, we want to apply it.  In tech, this is a quick step. This is probably something that just happens naturally. We take that learning and then we apply it to our day-to-day role, or we apply it to an obstacle that we’re going to encounter.

And lastly, let’s test it. So it sounds a bit like it may be an exam or something, but no, it could be it could be any way to test it you want to. You can have a period of self-reflection, ensure that that activity met what you set out to do, but it could also be a workshop. Teach your learning to others. Now that does a couple of things: that gives another perspective on that content that you’ve learned, and your team can absorb it that way perhaps better, because you will hopefully be close to your team, and then you can spin it in a way that suits them. It also cements your own understanding. So there’s a concept or a theory that if you’re able to explain a topic well, and clearly you obviously have a good grasp on it, and this is what we’re trying to tap into here.

So, what can you do? You’ve gone through all these things and a conceptual layout of how we might be able to implement learning activities. So I’ll go through a few of them now.

The first thing is courses and materials, and this is what people typically think of as learning. It’s a very small part of learning, but courses and materials. So we could be watching YouTube courses, we could go away to a person-to-person face-to-face classroom-led course. Could also be materials – books, research papers, whatever it might be. But the key thing here to bear in mind, and what makes this powerful, and what brings the most out of courses and materials, is to do something, what I believe is a good thing to do, is what we do at Made Tech. We give a trusted budget to our team members and they’re able to select courses of interest to them. We allow varied courses. It’s not necessarily line manager-led. They don’t have to say you need to do this course to participate in this project. If I have a genuine interest in, in my world, a tech stack, I can go away and learn it, and I can take time out of my day job to learn it. It’s really, really vital to give that autonomy and give that trust. It encourages their passions to grow, encourages the team passion to grow, and you’ll end up with a highly skilled and a more T-shaped person, that’s able to overcome more obstacles and share that knowledge around the organisation.

Communities of practice: You may already have these. All they are is a group of people who share a common concern, a set of problems or an interest in a topic. They come together to fill both individual and group goals. What they often do is focus on sharing best practice, creating new knowledge to advance that domain that they’re that they’re based in, and they often interact on an ongoing basis, which is an important part of this.

So I view these three pillars as key things to bear in mind when trying to set up a community of practice: The people you select (or the people that you open up to) need to have a common interest in that domain, and they need to be have some level of competence in it. Certainly encourage people from all levels, but they need to be at least a bit familiar to give a valid viewpoint. Next they need to have a commitment to that domain too, so it ties into the third column there of practice. You need to encourage a community, so ensure there are joint activities everyone can participate in. There’s forums to share their knowledge. And what you’ll find is that they form strong relationships within this community. And lastly, practice, which I hinted on, so each person attending a community of practice will be a practitioner in the in the domain that they’re a community of. So they’ll inevitably have a repertoire of resources that they can draw upon to contribute.

The next thing is workshops: So I said before, workshops, and I think I mentioned showcases too, now they’re sort of intertwined. We’ll talk about showcases in a second, but workshops are regular sessions covering any topic of interest. Sounds very general, right? That sounds like a day at work maybe, but let’s try to narrow it down a little bit. So what I’ve done in in teams is set up things called learning sessions. So every week we carve out an hour of our time, and everyone within the team gets together and shares a topic of their interest. It doesn’t have to be related to the project that they’re working on, or even the industry that they’re in, but what it is is an opportunity to discuss and maybe form opinions on other practices and other domains of knowledge outside of their day job. Certainly it can be on project topics, and it’s a great avenue to inject some quick learning into your team, or maybe there needs to be a critical awareness that has cropped up. It’s a great avenue for that. Try to rotate it around your team members. A good thing to do here is invite other teams to come in and present, and once you’ve done this trial run, build it up and invite other teams to attend as audience too. So then you have this brilliant forum of sharing ideas and discussion. In my experience, what often happens is more than half of that allocated hour or half an hour is dedicated to discussion, and this is probably the best thing you have from these workshop sessions. It’s that engaged learning, that proactive nature of your team, as they become more inquisitive to find out more about the topic being taught.

Showcases: So it’s kind of similar, right. What I mean by showcases is showing off a piece of work that you’ve achieved. Again, in my world, we are currently operating two-week sprints. At the end of each sprint, at the end of each piece of work, we’ll show it off to our peers and our stakeholders. And if you can do this as often as possible, this tightens that feedback loop that we’ve been talking about. This tightens it up so that we can get a quick reading on whether what we’re producing is the right thing. If you can show off your piece of work incrementally to a customer it’s even better, because they can see the development and how the work that they initially set out for you to do is growing.

I touched on it before, but cementing understanding by teaching. It’s a really powerful tool to enable a team member to talk about the work they’ve achieved, and maybe the obstacles they’ve come through, or how they’ve tested it. And it really gives you that whole picture and understand the audience, why that piece of work is the way it is. You get a great deal of satisfaction, engagement from the team itself who are presenting or have been involved in that work. If I do a showcase and it goes well and the customer says they’re happy with it, then there’s a great sense of satisfaction for me and also my team members who have inevitably helped work on that piece of work.

Retros: Bit of an Agile thing, but retros are great. I really like this quote from Thomas Edison: “I have not failed, I’ve just found 10,000 ways that won’t work.” That’s kind of what we’re trying to do now. It’s a platform to celebrate success and ponder upon failures, and what they are is… it’s a meeting, right, you bring everyone together, you try to encourage a comfortable relaxed environment. If you’re in person, take out the sticky notes. If you’re a remote you can use tooling that’s available online. You can message me on Twitter if you need some examples. What you do, you allocate some time at the start for each team member to talk about three things, make a note of three things… You can divide these out into how detailed you’d like, but what you want is – what went well, what didn’t go so well and some gratitude. You’re not demanding gratitude, you’re giving people a space to give thanks.

So the first thing  – what went well? We want people to recognise what went well in that iteration. So retros can be, in terms of cadence, these can happen every two weeks, every week, every day… We want to know what went well and what we should keep doing. We want to note these, right, this is obviously something that the team enjoys doing, so we want to note these and bring them forward in the project.

What didn’t go so well? So when you think about what obstacle we weren’t able to overcome, or why something’s different, or a particular pain-point in that team, these are really valuable. And this is why it’s even more important to build an environment of trust within a team, so they feel safe to voice their opinions. And on that note, something that you should probably do before a retro is hold an anonymous safety check, and all that is is to make sure that everyone is happy with voicing their opinions. You may find out that some people aren’t, and then you need to perhaps work on that.

And the last thing is make it fun! I needed to say that, as I said, needs to be a comfortable relaxed environment, ensure that it’s a fun environment too. Otherwise it’s very easy just for there to be silence. People put up their notes and there’s no discussion. Make it a happy environment, throw a ball around or use some online tool that has some fun theming, but yeah, key to make retros fun.

Now, next up is pairing, and I thought about pairing and this often comes up, you know, it’s often described as paired programming, and it’s quite specific to coding right? But not really. I was looking at the benefits and what do we get out of it. We get a great level of knowledge sharing, particularly if you have a more junior person and a more senior person working together. We have closer teams, so spending a lot of time together inevitably builds up a strong bond and a good rapport with the other person. There’s less downtime too, so if I’m pairing with another engineer I’ll be very conscious that I’m taking up their time if I go for a break or something.

There’s a piece of software called Tuple – and I give them full credit here, because they have a great deal of research and guides in how to pair effectively. Hit me up for the link if you need that afterwards. What it does, it describes in a slightly technical way, not technical… through a software lens, but you can still apply it to your teams. It is collaborating, that’s really what it is fundamentally, so what they’ve got is a handy little guide to getting started.  I was looking through this, and the only thing that’s really tech-focused is step four, so I just crossed out, we can ignore that one. So the first thing is agreeing on a high level goal out loud. The key to doing this is ensure that the goal is clear, you can articulate it well and that you’re both aligned. So you and your partner are both aligned. The next is to break the work into a handful of chunks. So there’s a few aspects to this. So the high-level goal is really say what you want to achieve at the end of the day. Maybe let’s break it down into small tasks, so that by lunchtime we can reflect upon those tasks and see if we’re making progress. It’s good to prioritise them, get the hardest things or the things that are time-bound over first.

Next we decide on driver and navigator strategy. In coding, it’s quite easy, one person is driving, so they’re typing away and the other person is navigating, so they’re keeping a bit of a distance and they’re commenting and they’re maybe advising, and keeping that high level goal in mind, maybe the tasks of what we’re working on. But it’s the same in any other team, so have you both sit around the same computer or on a call working on the same document, and have one person sort of take control, do the actual typing or drawing or whatever it is you’re working on. Now if the other person almost provides that constant review, that constant critique of what’s going on, in time you’ll find that as trust grows you’ll build a rapport that allows you to be more honest with this.

Eliminate distractions. Yeah, close Slack, put your phone on silent, notifications off. Do the work itself. And lastly, analyse that session with a mini retro, so at the end of your days carve out five minutes and just go through those things. What went well, what didn’t go so well, and thank your partner for maybe putting up with you if you’re a bit moody or whatever it is. Just be sure to try to get those retros in there.

Peer reviews: I’ll skim over this, but peer reviews are incredibly valuable. Now, what you’re doing with a piece of work, once you’ve gone around that cycle and it’s been tested, at that point – that’s when it is released to the business. That’s when it’s released to the larger organisation as an output of that team or as an outcome of that team. So really a peer review is almost like the gate that something needs to pass through to be released, to be achieved. And what this does, it allows everyone – all stakeholders, team members – to critique each other’s work and find the best form of it, and ask why that thing has happened. It really does weaken the idea that contributing is a private activity. The book “Team Topologies” talks about the idea that the smallest measurement in an organisation is a team and you shouldn’t think any smaller than that. So it enforces that idea that outcomes are team-based.

And lastly it develops the idea of the ability to appraise your own work. If I’m working on something, I no longer think that “oh it’s fine, I can just slip it into the workstream or slip it into the project” – it’s going to be looked at by many eyes, so I should think about it critically and completely neutrally.

Feedback is a big thing. Feedback is something that we’re huge fans on of Made Tech. Our COO, Chris Blackburn, he shared a blog post a couple of years ago about feedback. He goes into it in great detail about how to implement it, and our experience running with a feedback culture. What I’m talking about here is not traditional performance reviews where goals aren’t regularly tracked, feedback sessions are overly time consuming. I’ve been in teams where they would dedicate an entire month to one-to-ones and feedback because it’s annual appraisal time, and it’s just not the right way to work, I don’t think.

What I’m talking about here is feedback that isn’t owned by a line manager, it’s owned by the self. So how do we do it? Start with a small group. Let’s test it out first, let’s read that blog post, let’s watch a few videos or find a coach who will be able to teach you on how to deliver effective feedback. Ensure it’s timely. Don’t wait a week to deliver feedback, get it in as timely as possible. If it’s really harsh maybe sleep on it, but constructive feedback is incredibly valuable. How do we grow if we don’t know that we’re doing something wrong? Provide a framework for this, so this may be a piece of software that allows people to submit private feedback and public feedback. I’ve talked about sharing feedback on Slack, that’s a good place to do it.  In person is also great. And keep up that momentum. It’s really easy just to implement something then let it die after a few weeks. Be a champion for feedback. The responsibility is on everyone, it’s not just the managers to own. This feedback is for you, to help you grow as a person.

So we’re nearing the end now. We’ve covered that learning is a thing, continuous learning could be a thing, you have services that you need to deliver, and that ensuring that your learning is working well and that you’re continuously learning is intrinsically tied to the quality of your service and the customer satisfaction. We’ve looked at the pitfalls that we could encounter if we neglect this aspect of your team’s journey. And we’ve talked about – maybe a concept that we could take from my world and then apply it to any team really – it’s just that idea of continuous improvement. Keep that cycle going. So all the all the examples I talked about are things that are small enough to be done multiple times a week. The team journey really does impact that end result.

One last thing now. So this is a slide that I’ve stolen from my colleague Scott Edwards, from one of his webinars. He was talking about software here, but I really think it’s a good point to make. Taking that first step is really important, and it’s often the hardest one, but remember nothing will change until someone gets up and starts. So we’re thinking about the fact that if we implement one of these things – if you do a workshop or you do a retro – and it wasn’t quite perfect, keep at it! You can only improve. Make sure you have that mentality of growth. Build or do the thing, measure how it went and then learn from it. Just focus on those small incremental improvements and compound returns. And yeah, as always, you’re more than welcome to speak to us, if you want to chat about this more. And with that, I will hand back over to Jack.

Jack: I’m with you, and thank you very much Toby for that, that was absolutely fantastic. Which brings us to the Q&A section of our presentation.

Our first question is: “I am feeling unempowered in my team because I am not trusted to make autonomous decisions. What can I do to gain that trust and autonomy?”

Toby: At the end I talked about taking that first step, and the key here is to start small. So perhaps start with feedback, and start by building that that trusted relationship. And as you build that, you’ll be able to show that you have that trust and you have that determination to deliver on one of these examples. So I’d say to start small is the main thing, and as you build up these things as it becomes repetitive, you’re able to repeat it, you’re able to carry this out for a long length of time. What will happen is, people will view that as you taking ownership of a learning activity. And what will come with that is that autonomy. You’ll gain that trust from doing so. I hope I explained that well.

Jack: Excellent. Our next question is: “Any more tips for hybrid meetings please? A few in the room and a few online including me as the host.”

Toby: Oh gosh yeah it’s tricky right because you have some people in the same room and they’re able to talk with each other. I think the key is to… so there’s something that we implemented in our stand-ups day to day, and we put up a hand before anyone talks. To me the biggest obstacle with these hybrid meetings is smaller conversations going on when people are in the same room. I hope that’s what I’m getting, what you’re referring to. So what we do is before anyone talks we raise our hand, and we make that default for everything. And now it’s unconscious, right, if I ever want to talk my hand will be up. Try to put that into your meetings. It’s a little bit tricky when you’re in the office as well, but try to come up with some sort of visual sign that that person wants to say something, and hopefully that should streamline the conversation.

Jack: Excellent. Our next question is: “How do I get more people in my team to get involved in delivering learning sessions?”

Toby: Yep, I’ve encountered some similar issues. What sometimes happens is you say I’ll do some learning sessions, and a month goes by, and the interest may start to start to wane a little bit. The key is to keep it interesting, right, so if you just keep it within the team, people will… not get bored, but they’ll view it as somewhat samey, that they’re always having maybe the same people talk, or it’s always the same topics of conversation. So try to reach out to those other teams and see if they want to show off their work. You can combine this showcase workshop session. So showcase is normally for your own benefit and your projects benefit; when we talk about workshops it’s more about the individual and the team. So this is a great forum to encourage another team to show off some of their work, and it may even spur some discussion out of that. So I recommend trying to reach out to other areas of your organisation.

Jack: Brilliant. Next question: “Hi Toby, big fan! Great topic and presentation. Where would you start as a developer to introduce continuous learning into a company that doesn’t believe in or has never invested in continuous learning?”

Toby: Similar to the first one, I’d say to start small. Pick a small team who will be a good candidate for this – an engaged team. Start introducing topics of their interest, and start keeping that regular cadence going, so have a recurring one-hour slot every Friday or whatever it is. At the end of every day, book in a five-minute retro with a partner, someone that you’ve worked with that day. And try to keep those little things trickling into the day-to-day culture of your team. As I said at the end there, you can’t achieve everything at once. So start small, starting implementing maybe one or two of these suggestions I’ve said, and I can always guarantee you before long you’ll start seeing the fruits of it.

Jack: Brilliant. Our next question is: “Pairing seems like an expensive way to work. How is it justified?”

Toby: Yeah, I totally get that, and that’s one of the main criticisms of pairing, where you have two engineers working on the same piece of work, when they could just be working on two different pieces of work. And yeah, upfront there is a larger cost because you have a greater cost in terms of resources and people working on that piece of work. But what you’ll find is the benefits in a more accurate piece of work – a more accurate result and a more accurate outcome – more than make up those costs. And you have a lot of fringe benefits too, so you don’t need to think as much about knowledge sharing. I’ve worked places where we have a great deal more senior engineers who may be retiring soon, and how do you download that knowledge into your more junior engineers. And the same for any other industry. A pairing is a mechanism to do that. So you have that risk that’s completely destroyed by just by pairing. So these all these cost savings will come into it.

Jack: Lovely stuff. Next question is: “You talk about not ensuring learning is relevant. How do you weigh the organisational benefits versus the individual benefits?”

Toby: Yeah, so it sounds like I’m saying let that team go away and study Pokémon cards for a week, and it’s not really feasible, right, it’s a bit of a waste of money. Where are you going to see your ROI? What I mean here is introduce some sort of scope, so this is where line management can be useful. A line manager may advise on topics of interest or topics that could be beneficial to that person, to help them grow in their career. But don’t focus solely on the project at hand or the piece of work they’re currently working on, and don’t ‘gate’ a piece of learning. So don’t say that you can only do this if you’re going to join that project, that’s what I’m trying to get at here. Let them learn within reason, whatever they want to, to grow those passions. Ultimately you’re hiring passionate people to work for your organisation, and you’re hiring people who want to work there, so surely they’ll want to develop themselves and grow themselves to be better at their day job.

Jack: Absolutely. Next question is: “You mentioned learning being a default approach to solving problems. Should this always be the case?”

Toby: Yep, next question! What I mean here is that we shouldn’t look at look at an obstacle – I think I said this earlier on – that we shouldn’t look at obstacles immediately, oh no let’s hand it off to this team; we should look at it and say, okay I don’t know how to do this now, how can we learn from this? Or, what have we done in the past that’s led to this? We should always view it as a means to learn. And the activities that we talked about at the end there, you can bring that problem into a workshop, that’s a valid workshop topic, and then you have everyone’s input on it. You can collaborate with someone, so find a pairing partner, and both sit down at the same desk, or get on a video call and chat about that same problem. So this is what I’m talking about with making it a default. Use one of these mechanisms to learn from it and collaborate.

Jack: Excellent. “You spoke about decreased costs. How does this continuous learning approach lower our costs?”

Toby: Sure yeah, so when I say ‘cost’ I’m talking about time. I’m talking about work hours and people hours. Quite simply, you can do a course – it’s two weeks long, three weeks long or something – you don’t really know until the end of it whether it’s beneficial, whether it aligns, without some feedback. So the good thing about doing this small incremental continuous approach is that we do these little and often sessions. We can very easily course correct. So we don’t waste time doing big expensive courses. And that’s really the only point I’m making there, is that there’s a great benefit to doing these things little and often. We get that compounded knowledge gain, but we also are able to make sure that what we’re learning is accurate and best suited to us and our teams.

Jack: Brilliant. I think we have time for one last question: “Could you share the URL of that feedback blog post you mentioned please?”

Toby: Yep, no worries, I’ll put on Twitter or I’ll speak to Jack and we’ll get it on Made Tech social media.

Jack: That’s all the time we have for Q&A, so I just want to say before we get started on the outro, a massive thank you to Toby for taking the time to speak today, and a huge thank you to all of our attendees who came by this afternoon.

As we mentioned previously, we will be sending out feedback forms to all of our attendees today. Like I mentioned before, they’re very very short, they take about a minute to fill out, and they really do help us to improve our events for the future.

I also mentioned we’d talk a little bit more about what we’ve been up to. Out now we have our Made Tech podcast, Making Tech Better, hosted by the wonderful Clare Sudbery, one of our lead engineers here at Made Tech. The first 11 episodes are available on all major platforms for you to binge at your disposal.

And last of all, absolutely stay in touch! Toby’s Twitter handle is up on the screen. If you want to find out more about what we’re up to, you can find us at www.madetech.com – or if you want to reach out to us directly or we didn’t have your question answered during the session, please do reach out to us on Twitter – we’re very very active. And with that, I will wish you all a very lovely afternoon and thank you for coming by!

[Recording Ends]