Jack: Good afternoon, and welcome to our third Made Tech Talks webinar: “How to upskill your technical teams effectively”. Our speaker today is our very own Scott Edwards, one of our Senior Engineers here at Made Tech.
Before I hand over to Scott, I’m just going to run down how today’s going to go. It’s going to be a 45 minute presentation from Scott, followed by a 15-minute Q & A at the end. So please make use of the Q & A function found at the bottom of your screen, and we will endeavour to answer as many of your questions at the end of the webinar as we can.
After this webinar we will be sending out feedback forms just to get your thoughts on what you’ve seen here today. It takes about a minute to fill out and goes a really long way for us improving our future webinars and finding out what topics you want to hear more about in the future.
We’ll also be providing a little bit more info on our next Made Tech Talks webinars coming out, as well as a little bit of information on our ebook “Building high performance Agile teams” – and where you can get your copy if you haven’t got one already.
This session does come with live subtitles. Information on how to get those could be found in our chat function. We’ll be putting out the information a few times just in case you missed it. Also this session is being recorded.
And so without further ado, I’m going to hand over to Scott. Scott, if you want to take it away.
Scott: Great, thanks Jack. Hello everybody. Thank you for attending our session today. Thank you to Jack for your intro. Today’s topic: “How to upskill your technical teams effectively” is something we’re pretty passionate about at Made Tech, so I’m excited to talk to you about it, and we’re going to be focused on three main areas today:
So, first up, we’ll run through the benefits of upskilling your technical teams.
Secondly, we’ll chat about communities of practice and how they fit into the upskilling Process. And finally, and most importantly, we’ll give you some recommendations for beginning the upskilling journey in your own organisation.
Before we begin, let’s just make sure that we’ve fully understood today’s topic. You may be asking yourself – why is this important? Or even – why should I care about the subject? The answers to this question run as a strong thread throughout the webinar today, and as we progress we’re going to look at the benefits for your organisation and teams, and also discuss some of the long-term cost savings associated with this process.
Additionally, we should define what we mean when we talk about a ‘technical team’. Are we talking about just developers? What about testers, business analysts? What about product owners, researchers, content writers, delivery managers… and the list goes on. The short answer here is that the term ‘technical team’ encompasses all of these roles, and anyone else involved in the delivery of your technology project. There’s no point in just upskilling your techies if the other people in your teams can’t talk the lingo and are going to become a bottleneck.
So, with that out of the way, let’s talk about the benefits of upskilling. Before we dive into organisational level benefits, let’s have a look at the benefits that the upskilling process provides directly to your teams and your team members.
We’ll start with an important point, and something that I can talk about from experience: Working in an organisation with a strong culture of learning and continuous self-improvement keeps your people excited to keep coming into work every day. As technology advances, our technical teams need to constantly upskill to avoid being left behind. This can be a fairly stressful process, to keep up with these fast-paced changes in the tech world, and being given this opportunity by your employer is seen by technical teams as a massive perk. On the other hand, when people aren’t learning and growing in their roles, they do tend to think about seeking out new job opportunities where these perks are available to them, and you risk losing people as a result.
Our next point is a bit of a shared benefit between individuals and organisations, and that’s that happy skilled teams tend to produce better quality work. When you’re happy in your role, you tend to want to produce work that you’re proud of, and these ideas about team satisfaction lead us nicely into one of the first benefits for upskilling for your organisation, that being retention. Now I’m pretty sure everyone is well aware that training new starters is a very expensive process. Onboarding causes a dip in productivity, and you have related cost implications as you bring your team members up to speed. You will inevitably lose some technical domain knowledge if your people leave, which means that your new starters have to waste time rediscovering this knowledge.
And over and above this – and this is something I tell my friends and colleagues all the time – people talk! If they’re acting as evangelists, talking your organisation up to their friends and contacts in industry, they’ll be helping you to organically attract new strong talent to your team. And once again I can talk from experience as a technical team member here – it’s pretty important to me to work for a company that gives me structured time to focus on becoming better at my job. I joined Made Tech on a friend’s recommendation, and his descriptions of the learning culture were a strong draw card for me. And I know of several people on my team for whom it was a selling point in the interviewing process as well.
Moving on though, to what’s probably the most important point on your screen at the moment: increased internal skillsets lead to more effective deliveries. So what do I mean here? Well, let’s look at some high-level examples drawn from our communities of practice, which is a concept we’ll look at in more detail later to illustrate this point.
Unsurprisingly, we found that upskilling our developers in a broad range of technologies and modes of thinking as well, gives them a better ability to select and use the correct tool for the job. We’ve also found that teaching our other technical team members – say our business analysts and our product owners, our delivery managers – how to effectively communicate their needs to development teams, reduces the risk of misunderstandings and the related wasted time and opportunity costs. And we’ve also found that teaching developers how to think in business terms gives your teams a better shared understanding of why they’re doing what they’re doing, with similar benefits to the previous point.
Additionally when you’re providing the opportunity for your team members to upskill, you get to choose and prioritise the skills your organisation needs, rather than hoping that your people are learning the skills that are useful to you and your organisation in their own free time. For example, you could be educating your teams around cloud computing concepts and providers, because you’re aware that you’re facing an inevitable cloud migration in your future. And from a modernisation point of view, we all know that the technical world is constantly changing and you don’t want to be left behind. You should be empowering your teams to tackle modern challenges internally – things like cloud migrations, automation via DevOps thinking, and whatever else comes up next in this ever-changing crazy technology world.
We see time and time again where locked-in legacy technology and a lack of internal modernisation skills enable incumbent vendors to maintain hold of the organisations that we work with. What do I mean when I say ‘incumbent vendors’? Well I’m talking about those large system integrators who provide expensive technical services to you and your organisation. They provide those services that your team could probably upskill in if you empower them to do that, to get involved in that upskilling process. And some examples here include software development teams, technical operations teams, testing teams, the list goes on. So we’re talking about empowering everyone in those technical teams.
So wouldn’t it be great if you could upskill your internal technical teams to tackle any challenges that come their way and take on modernisation efforts themselves? If you want to start enabling them to do this, how should you structure the training to get them there? With this question in mind, let’s move on to communities of practice.
So, we’ve chatted briefly about the benefits of upskilling your technical teams. Now a great way to implement your upskilling programme is via communities of practice. So what is this thing, a community of practice? Loosely defined, it’s a group of people who share a passion on a particular subject, and they regularly come together to learn and improve in this area. You can maybe view it as a way to structure collective learning in a shared domain. They’re a pretty useful metaphor to add structure when teaching a group of people to become extremely skilled in a particular area. We keep coming back to this point: they don’t necessarily need to be technically focused. So for example, internally to Made Tech we Run communities of practice for our engineering teams, our delivery teams, our marketing teams, once again the list goes on. These can be as simple as Slack or Microsoft Teams channels, where people with common interests share new concepts they’ve learned, links to talks, interesting articles and so on. Or you could have a larger community of practice structure with regular time-box learning sessions held over the course of a few weeks or months. These help you make sure that a particular concept is deeply understood by your team – an example being running through the GDS service standards.
So, this sounds great. Why are they important? Why do we like these things? We like the fact that they give us a way to structure our approach to learning and upskilling. In our case as a consulting company, our product is our people, so naturally we need good people to provide a good product, and our communities of practice help us to keep our people up to date with whatever skills and knowledge they need to effectively deliver day-to-day in public sector organisations. If you’re providing learning time, you should maybe be approaching communities of practice more like a product company would, and thinking about whether you’re getting the best output from your people to deliver your services. And if not, is it due to a skills gap? And could upskilling actually help these people to improve their performance? Are there perhaps specific skills which your people could learn and teach on to their teams to achieve your goals?
So, this sounds great, what’s our approach? In Made Tech’s case, we set up an internal community of practice in 2017, which we creatively named ‘Learn Tech’. This is a half-day of focused learning every Friday afternoon after lunch – and important to note here the entire company attends, not just developers – and attendance is mandatory for everybody. It’s planned out in collaboration with both our management, our people and our senior technical teams, and they kind of work together to define the amount of learning time available to our people, how to structure the time and the sessions, and the range of subjects and learning tracks provided. Additionally they focus on gathering feedback from our people and whether the skills they’re learning are actually aiding them in their day-to-day deliveries.
And for a couple of examples, we’re currently running our pre-built ‘Learning Tracks’ – these being public sector – which teaches people how the domain we specialise in actually works. ‘Methodology’, which is a track mostly for non-developers, for example content designers, the marketing team, researchers. This shows them how software development processes work, how developers think, and enables them to better collaborate with their development teams.
We also have a track called ‘Commercial’ – otherwise known as “how does Made Tech actually make money?” – which is where we give our people an understanding of how the businesses run overall. Things like how big bids are written, how we grow the business, how we advertise, how we market ourselves, all that sort of good stuff. When these tracks are running, our people get to choose which track they believe would suit them best, and we’ll often chat with our People team to get a better understanding of what each track is about before making a choice which one would serve them better in enhancing their day-to-day delivery.
Over and above those three that I mentioned, we also have technical learning sessions for developers, with a little bit of fun and gamification. So these are structured and goal-oriented learning tracks. For example, we have a track with focus on test-driven development, which you in that track you learn by practising test-driven development. There are a predefined set of outcomes, which we demonstrate in pairing sessions with more senior colleagues.
And you may have been wondering about this image on your screen with the giraffe, the wolf and the dragon. So these are the levels we’ve defined for that learning track, and these are awarded as stickers for your laptop once you’ve passed each level. These are kind of worn as a badge of pride by Made Tech staff on their laptops, to show that they’ve got the skills and they’ve proven it.
So, this all sounds great. How has this community of practice actually benefited us? The prime benefit is the upskilling of our people of course. This enables our teams to deliver better work for our clients, and happy clients equals happy Made Tech. But we have noticed additional benefits too. For example, we have been fostering cross-team understanding and communication, and sharing knowledge with other teams about how they solve challenging problems day-to-day. These are teams that you wouldn’t necessarily interact with in the normal course of your work, because they are working on something completely different or maybe you’re in the Bristol office and they’re in the London office.
It also helps us to build this strong organisational culture of helping each other across the streams; we’re not these little silos that never ever communicate with each other. And it gives our technical team members some insights into some of the processes that public sector departments and commercial organisations use behind the scenes, because at the end of the day it’s not only about code and technical deliverables, there’s a lot more to running a business than that. It also gives our team members who don’t code a chance to understand all of this gobbledygook that us developers speak all day, and to ensure that we’re not just making up words to have a laugh, these things are actually real concepts.
As I mentioned earlier, it’s also a pretty big draw-card in attracting talent to our business, and overall we found that our people love being given this chance to learn and improve, on company time.
Our biggest learning so far in improving Learn Tech as a community of practice has been to constantly seek out feedback from our people. This allows us to iterate and improve on our structures, and we’ll talk more about that a bit later. You’ll see a link on your screen: If you’d like to have a look at that at some point, that is basically the open-source link to where all of our Learn Tech structures are defined. You can go see all our different learning tracks and descriptions of how we run them. You can go look at things like the giraffe, wolf and dragon TDD levels and various other things if you’re interested. So please feel free to have a look around there.
So before we move on, I thought it would be cool to show you some pictures of what Learn Tech sessions actually look like. So we’ll start with what it used to look like. In these photographs you can see some of our people attending sessions in person in the office. If you look closely, you’ll see that the session on the left is focused on consulting skills and the one on the right is focused on developer skills. Just a note – we have purchased some more chairs since we took these photos, so you actually get to sit down while you learn!
But right now, obviously given current circumstances, this is not possible. So this is what Learn Tech currently looks like. We’re not able to hold large in-person group-focused meetings right now, but we’re still making it work remotely. So on the left you can see the kick-off meeting which happens just after lunch every Friday, which the whole company attends, 63 people in that one. This Friday there’ll be a hundred, which is a good opportunity for everyone’s laptop fans to start working overtime as 100 people join a conference call at the same time! And then on the right hand side you can see a session being run remotely. So this is an actual Learn Tech track being run. If you’re able to see the guest list, you’ll notice it’s a lot smaller because people are focused on their particular learning track. We hold our community of practice as an integral part of our culture so we’re not prepared to let a lockdown get in the way of upskilling our teams. Of course there are challenges to running it this way, but over time we refine the process for running it remotely.
So if I’ve done a good job at this moment, I would be hoping that you’d be thinking – hey, this sounds pretty great, I’d love to implement this practice in my organisation. But if so, you’re probably also thinking – what is this going to cost me? So let’s talk about costs, otherwise known as ‘the elephant in the room’ – using this classic cartoon this shows the most common dilemma when it comes to investing in your people. So what if you train them and they leave? And yes, this happens, and it’s a risk you have to accept if you choose to upskill your people. But what if you don’t upskill them and they stay? Well then you end up with internal technical teams who lack some of the knowledge and skills required to actually perform their roles effectively. And when I’m talking to you about training and upskilling I’m essentially asking you to take time away from your people during the working week, and to reduce their productivity in the short-term; but in the long term you should actually see an overall boost in productivity.
And there will naturally be costs involved. These will vary by the size of your organisation, the types of skills you aspire to teach your teams – for example, in Made Tech’s case, we lose half a day’s billing across the entire company every Friday, but we look at upskilling as an investment in our organisation and its people, rather than just a cost. So we believe that you should be viewing it this way too, and also look at it as a force against the risks of staff turnover, the inability to maintain your own products owing into skills gaps or skills islands, and especially against the high cost of bringing in expensive consultants when your teams don’t possess the skills needed to execute your plans. You’ll remember that we mentioned the long-term cost savings earlier, and this is one of the areas where we expect the majority of your long-term benefits and savings to come from.
So let’s assume we have you convinced. You think upskilling your people is a great idea. How do you actually go about getting started? We’ve spoken through what a community of practice is, let’s talk about getting going on this journey in your organisation. So first up, some general points. Before we get started onto the process itself, an important question to ask yourself upfront is – Is there a ‘one-size-fits-all’ solution to upskilling my teams? In other words, is there an out-of-the-box solution for all of my training and upskilling needs? Well yeah, if only life was that simple! The approach you take needs to be adapted to your organisation’s specific needs, and so no two upskilling strategies and journeys will be exactly alike. With that being said though, we can focus on avenues of exploration here, to guide you on your team’s upskilling journeys.
Another point to note is a question to bear in mind across this entire section: So what keeps you and your leadership teams awake at night? If you perform a strategic role in your organisation, there’s a good chance that the answer here is future planning and risk mitigation, and this is a good guiding thought to bear in mind as we run through this process. Additionally, as we run through this process and talk about strategy, we’re going to be using the real-life example of an organisation that was in quite a bit of trouble and needed some help upskilling their technical teams. Some parts of the story are left deliberately vague to protect both the innocent and the guilty, and we’re going to refer to them as our ‘example organisation’.
So, a bit of context on this organisation: The systems that they were responsible for had direct impact on everyday citizens. They built these systems in the past, using what was now a fairly ancient technology that was out of support by the vendor. There was no modern language use and there were no automated tests. They had used up an entire datacentre and literally could no longer expand, as there was no physical server space left to host them any more. They had no failover plans and no failover systems, so if the system failed, it failed. This was exacerbated by existing stability issues, which were keeping support teams busy day and night, including – unfortunately for them – over weekends. And it took on average about six months to release a small single new feature. The team that had developed their service was long gone. Well, the team that had originally developed it was long gone, and they had taken their technical and domain knowledge with them. So, I think everyone will agree that this organisation was in fairly big trouble. Luckily they acknowledged it and were facing up to the challenge.
Their teams didn’t have all the experience and skills required to execute their plans, and so they sought help, and it became clear fairly quickly that they needed a bigger focus on empowering their own teams with the skills needed to dig themselves out of this hole. In an ideal world they would have been able to upskill their teams to solve their own problems rather than bringing in consultants with the required specialised skills. However, they had this immediate need for expert intervention, so they were focused initially on outsourcing in the short-term.
And this leads us to an interesting question you should ask yourself: What type of work do you repeatedly have to hire contractors and consultants for, and wouldn’t it be more effective if you upskilled your own internal technical teams to perform this type of work going forward? Now there’s nothing wrong with needing to hire or outsource before you grow your existing teams, but if you do we recommend hiring people who both have the skills you need to execute and deliver in the short term, and possess the drive to pass their knowledge and skillsets onto your existing teams as they work together.
If you do decide to start upskilling with existing teams, you’re probably looking at strategic rather than tactical timelines. Fostering this culture of learning and constant improvement is an incremental process which takes time to get right, and your long-term focus should be on building high performance internal teams. You may be asking – what do I mean by high performance teams? So I’m talking about teams with an inherent culture of trust. Teams that have tight experimentation and learning cycles with that learning culture baked-in. The sorts of teams that treat challenges as opportunities for learning and improvement. And coming back to our earlier concept – Interestingly, communities of practice tend to naturally emerge as components of high performance teams.
A bit of a shameless plug here – If you’d like to learn more about this idea, we have written a book on the subject, and Jack will give you some information at the end of this webinar on getting hold of a copy for yourself.
So let’s move on, and let’s talk about the actual strategy for upskilling your technical teams effectively, and also see how this pro approach helps our example organisations or organisation to pull themselves out of their pit of despair. When you define your upskilling strategy… we recommend that you utilise a phased iterative approach. We’ve defined three repeating tactical phases for you, the first of which is information gathering. So this is all about understanding before executing. You could also refer to it as a capability assessment if you like. We recommend starting out by getting your senior stakeholders into a room together to kick this process off. And when I say a senior stakeholder, I’m talking about your colleagues who fill strategic roles in your organisation, those who are ultimately held accountable for the successful delivery of your services. Examples include technical architects, CTOs and other senior responsible owners. We would expect people at these levels to have a broad understanding of the challenges the organisation is facing, as well as direct links into their teams if they need to gather any additional information. So in the case of our example organisation, this list included amongst others, the Chief Operating Officer, the Lead Architect and the Delivery Management team.
Once you’ve gathered these stakeholders together, your first step is to map out as many of
your existing delivery skills gaps as you can. In other words, survey the landscape, ask yourself where are we struggling to deliver and are there any skills that our people lack that are causing these issues? If there are information gaps in this analysis, get your senior stakeholders to drill down right to the individual level by interviewing your technical team members to understand their daily challenges.
Your next step is to collate all of this information and break it down into two categories. The first category is short-term immediate skills gaps that are hindering delivery and need to be filled right now, for example by new hires or by consultants or contractors.
The second category has a much more long-term focus and consists of skills gaps that you predict will hinder achieving your strategic objectives in the future. This one is much harder to evaluate but I can give you an example of a way to think about it. So let’s imagine that you have a cloud migration scheduled to kick off in six months time. If so, have any of your technical team members actually worked with your cloud platform of choice before? Do they understand the difference between a ‘lift and shift’ and a full-on cloud migration? Do they understand your existing technology base well enough to start thinking about how to migrate it to a cloud platform? So these are the sort of questions you can start asking yourself.
As mentioned earlier, be careful of focusing only on your developer skills here, so in the cloud migration example: your analysts need to understand this new technology landscape you’re heading towards, your product owners and delivery managers need to understand how to manage these sorts of transformations, and in general your entire technical team will benefit from upskilling in the various domains, not just the developers.
For our example organisation, both short-term burning gaps and longer-term skills gaps needed to be identified. So the first step in understanding these was to run value stream mapping sessions, to map out and understand the domain as well as the various systems and the modules that interacted within it. Once this was completed, the problems which the organisation was facing were mappable to the various moving parts within these value streams. This analysis was then broken down into short-term challenges that needed to be resolved immediately and long-term strategic enhancements to bring the service under control.
Merging this information with insights gleaned from conversations with the existing technical team members gave us a fairly clear picture of where the skills gaps lay. Mainly migrating a code-base from legacy technologies to a more modern maintainable architecture. That wasn’t something any of them had done before. Bringing large systems under test to give teams confidence when making changes – it was not also something they had done before, and they didn’t have an understanding of cloud-native thinking and the process of shifting existing on-prem systems to cloud-hosted infrastructure.
Now there’s an interesting point to note here, and that is there was a big level of passion within those technical teams at the example organisation. When speaking about their desire to learn and improve, they felt that they were so busy cutting down trees all day that they didn’t have time to sharpen their saws, and I thought this was really interesting. It showed me that people want to be good at their jobs but they need to feel empowered to improve their skills. Overall, I would imagine that very few people arrive at work and actively set out to do a bad job every day.
So, moving back to our three phases, at the end of this process you’ve got a good idea of your skills gaps, broken down into two lists: one lists the requirements for fulfilling short-term goals, and one is all about the skills required to fill the long-term gaps and enable your strategic vision. And this is where we’re going to be focusing our attention. This list of skills gaps leads us into phase two which is planning.
So, at this point, you have your skills list from phase 1 ready, and your first step is to evaluate and prioritise this list. So what do I mean by this? Well, when looking at the goals defined in your organisation’s long-term strategy, some naturally take higher priority than Others, and this priority list will help you to identify the most pressing skills gap in your technical teams in order to deliver these strategic objectives.
So let’s look back to our example organisation. Remember that they were facing those massive challenges, and overall the quality issues in their existing services were identified as the most pressing issue, as this was affecting their users on a regular basis. It was decided that until these quality issues were resolved, big ideas like legacy migrations, cloud-based infrastructure and so on, were off the table. They clearly needed to get their system into some sort of automated test harness, so that they had a way of guaranteeing, or at least hoping and ensuring that strategic work that they took on was not actually making things worse for their users.
This primary goal of getting the system under test was marked as strategic goal number one, and the process of teaching teams to think in a test-driven automated manner was the main component of that. Now, this is not a one-off process, and nor is it achievable in a single day or even a week of training. It’s a process that takes time, and you have to convince your people why your chosen approach makes sense before you teach it to them. In our experience it takes a couple of months at individual level to get people who’ve not worked this way before to a good level of competence to apply it in their day-to-day work.
So, looking at our example organisation, we had our direction of travel defined – we wanted to aim towards fully automated testing capability to the greatest extent possible; and at this point we could define smaller milestones on this journey, and these give the teams short-term goals to focus on, as well as a sense of pride once they achieve these goals. For example, could we give the technical teams the skills to enable them to automate the testing of a single section of the business logic?
Once these goals and milestones are defined, your next step in the process is to assess your
organisation’s internal capability to upskill your people. So what am I talking about here? Well, let’s use the example organisation again. They didn’t have the people available to train their technical team members, and so they had to rely on outside help to get going on this journey. They needed passionate people to work with their team members in this manner on a day-to-day basis, and to pass that knowledge over. That being said, your situation may be different, and you may have these capabilities in your organisation already. If they do exist, we recommend talking internally to your organisational teams who have these capabilities first. Perhaps they could help you to put structured learning tracks together for your teams to follow, based on their knowledge and experience in these areas. And if you don’t have this capability, you shouldn’t dismiss looking into high quality training courses as a good starting point for your people on this journey, if you find that you don’t have these skillsets available. Please don’t be shy to reach out to us at Made Tech. We love talking about this, and we’re happy to offer help, advice, guidance, anything you need. Just reach out to us whenever you like.
At this point in the journey, you also have some time-management decisions to make. You need to balance learning time and delivery time, and if you’re lucky you may be able to merge these two concepts. For example, in our example organisation the teams on the ground were merged with a set of consultants who were able to teach them these skills in their day-to-day work. But you could also look to follow our Learn Tech community of practice models with a set of preset times set aside every week for learning and development.
And the final, extremely critical, part of the planning phase is the definition of your measurement criteria. So these are important to define early on, because you need criteria to baseline where you are right now, and to use to measure your team’s progress going forward. So some typical examples could include the release cadence of your service, the speed at which your technical teams work through their sprint tasks if you’re using Scrum for example, the number of defects reported, or the volumes of user complaints. There’s a bunch out there that you can choose from.
So at this point in phase two, we have the plan laid out and we have everything we need to kick off your community of practice. It’s time for the most exciting phase, which is execution and measurement. So the first step is all about how you communicate this plan to your teams. You need to get your people excited about this, and you also need to show a level of empathy and understanding, because they may be sceptical. You need to make sure that they’re not looking at this as some form of mandatory training that just gets in the way of their day-to-day delivery, and you can do this by explaining your strategic reasoning behind the plans, and that communities of practice are there to equip them to perform their roles more effectively and to make their day-to-day lives at work more pleasant.
In our example organisation this was a fairly simple step, and we were lucky there the teams were frustrated with fighting fires, and so consultants were brought in to help with the firefighting as well as to give them some breathing room and some skills to pass over in their day-to-day work together.
We’d also recommend going a bit in-depth in explaining the concept of communities of practice to your teams. So explaining to them why you’re using this model will help to get them on board with your upskilling plan, and they also add a fun social element to learning. It helps to feel less like that boring mandatory at-work training. From personal experience, I look forward to Learn Tech every Friday – grab my lunch and then spend my afternoon learning – it’s brilliant. You should also explain to your teams that the time commitment required is part of their working day, as opposed to time over and above their working Hours, so you’re not expecting them to stay for an hour every day after work, or come in early or learn over their lunchtime. This is not built into their working day. You should also explain to them that this is an iterative process and that regular feedback is welcomed. We have found that hugely helpful.
You need to set realistic expectations. So let them know that this will be an ongoing process,
and let them know that say quality issues in our example organisation will not be resolved in a week. We’re working towards empowering you to tackle these problems on your own over time. You should also make sure that you set expectations with other teams that rely on your services. After all, you are going to be spending some of your business hours focused on this upskilling process, and so you may not be fully available at certain times.
And generally, when it comes to kicking off communities of practice, we find that iterative approaches are preferable to big bangs. As we all probably know, people naturally resist large changes – they find them disruptive to the day-to-day delivery responsibilities. So it’s preferable to start small, measure and iterate. This gives you a chance also to catch any mistakes or changes that you need to make early on, and to refine your process on an ongoing basis. Remember that small changes made over time lead to big changes in the long-term. In our example company our best measurement data-points came from two Places. The first was measured system error rates, including complaints from users. We found that those started dropping over time. And secondly, open and honest feedback from the technical teams – like were they finding these sessions useful, were they applying the lessons they learned day-to-day, were there other areas that they thought could be more useful to upskill them?
So I keep going on about iteration, so let’s just talk about that briefly. This upskilling journey is an ongoing iterative process, so you’ll find that once you’ve updated some of your goals and you’ve then met them and you’ve updated your measurements, you’re going to find yourself in probably one of two places shown in these two scenarios: Scenario A is where you still have an up-to-date list of missing skills from your initial information-gathering process, you’ve not finished working your way through the most crucial ones, and you can focus on planning the next phase in your upskilling journey and then move on to execution and measurements again. Sometimes you’ll find Scenario B – where you’ve worked through your list and you need to go back and perform that information-gathering phase, do that analysis to baseline your information again. This will help you to find the next set of skills gaps that are driving the constraints or causing constraints in your organisation.
And I feel like this is an important point to make, because this is an ongoing journey and there will always be a new skill to teach your teams to make them more effective. And there’s a quote that I really like that sums this up nicely, from Isaac Asimov, which is: “Education isn’t something you can finish.”
So let’s quickly summarise the key takeaways from today’s session:
The first is that there are many benefits to upskilling, both for your organisation overall and for your people. The second is that you should focus on upskilling your entire technical team, not just your developers. The third is that communities of practice are an excellent way to get started on this journey. And the fourth is that you should look at your costs as investments. While you’re on this journey you should think long-term, so you should be focusing on strategic timelines and you should be following a phased process that you can measure and iterate on. And that’s it for the section of the webinar. Thank you very much! Handing back over to you, Jack.
Jack: Brilliant, thank you very much Scott. Without much further ado, I’m just going to go straight into our Q & A section. Our first question is: “How do you start communities of practice? Does it have to be organic?”
Scott: Not necessarily. So if we look back to the Learn Tech example, that was built using communities of practice from the ground up, but it was built deliberately based on a plan rather than emerging organically. But as I mentioned, they do tend to emerge organically from groups of people who are passionate about a specific subject, so I would say the answer is – it depends – which is the most common answer developers will give you! Communities of practice can emerge both as organic entities from shared passion for a subject, or they can emerge from structure defined as a basis for an upskilling strategy.
Jack: Brilliant. Next question is: “Will this approach work for non-technical team members, e.g.
Managers?”
Scott: Good question. I would say so, yes. There are some distinct skills that managers at all levels need, so we’re talking about strategic thinking, communication up and down the chain, that sort of thing, and communities of practice would be a good way for them to meet, share and upskill in these areas. Interestingly, one of my good friends suggested something similar to me recently – why not set up a community of practice for CTOs and Technical Architects to share their challenges across various organisations, and talk about their solutions over coffee before work, maybe. Something where we can do some presentations and get people to get chatting about these things rather than solving these problems in isolation. This is something I’m actually thinking about doing post-lockdown because I would prefer initial meetings between people to be done in-person rather than over Zoom.
Jack: Awesome. “What measurements does Made Tech use for tracking the effectiveness of your community of practice?”
Scott: So when it comes to the coding tracks, this is fairly simple. Once someone’s been learning and practising a concept for long enough that they feel comfortable showing it off, they will pair-program with a more senior colleague who assesses their skills against a set of criteria. These criteria are known in advance by both parties. Sounds scary but it’s actually done in a really friendly growth-focused way with plenty of constructive feedback. And if you remember from the slides earlier – I showed the giraffe and the wolf and the dragon – I actually have one of those stickers here on my desk which I can show you. So these are actually a great way to track that stuff, because we’ve segmented that learning into very particular sections. If you’ve got this on your laptop – I should really stick this on my laptop! -you have a particular set of skills that you can be proud of.
Now, when it comes to consulting skills, or let’s say public sector knowledge, it’s a bit trickier to track and measure than technical skills. There are a couple of things we do here: We do a lot of group work in these sessions, and you get some very immediate feedback in group work on whether people are actually taking in what you’re teaching them, because we get those groups to present back to the overall learning session at the end of the process. And this allows us to kind of experiment and refine and see whether we can get our ideas across more clearly to those groups. What I tend to find is that the sessions that are done in more of a fun way, rather than just like 100 slides with 100 bullet points each, those are the ones that really get people’s attention.
And then we spoke about feedback quite a lot today, so that’s also a strong indicator of the usefulness of those sessions. So our People team and our Learning team draw that feedback out of everybody: whether those learnings are helping them in their day-to-day work. And we also have a mentorship structure internally. So when I have my sessions with my mentor, we often speak about the learnings from Learn Tech. I’m currently on the public sector track – I thought that would be the most useful to me – and whether I’m able to apply those learnings in my day-to-day work. So the feedback is brought in that way, and we’re not afraid to change Learn Tech to address these needs and these skills gaps as they are reported by our team. So I was chatting to our community manager recently, and she gave me a hint that the next evolution of Learn Tech is on the cards. That’s the most information I have so I’m pretty excited to see what’s next.
Jack: Lovely stuff. Alright, let me just find our next question. Here we go: “How do you generate buy-in from above?”
Scott: Great question. So this all sounds wonderful, right? And we’ve got that elephant in the room of cost – both mandatory and opportunity costs – and that’ll probably be the first objection you’ll get from senior stakeholders. So we had a similar situation when we created Learn Tech. It sounded like a great idea but we had to convince our financial teams and our senior financial managers that this was a good idea. And what we found effective was to go into those sessions fully prepared – so not just a casual conversation over coffee – we’ve really thought about this thing, we’ve got a plan in place, we can show the benefits, we can show yeah, a dip in productivity and maybe a dip in billing initially, but how it’ll pick up over time. And also going into those sessions prepared, expecting certain questions, as you would with any large presentation. You’ve got your expected questions list prepared and you know what you’re going to say, so that you’re not umming and ah-ing and trying to speak off-the-cuff.
I would say for a public sector organisation, your best selling-point is probably the fact that if you upskill your people internally, you’re not necessarily then going to have to pay expensive contractors and consultants in the future to perform those tasks that your people are now empowered to perform.
Jack: Lovely. Our next question is: “Hi Scott. Are there any situations where upskilling isn’t appropriate, and it’s best to hire/buy-in skills for a project or deliverable?”
Scott: Thanks, good question. I would say, if you are looking for very unique skills…So let’s say you’ve got this great idea that you want to build AI into your system for some reason – chatbots let’s say – right. I wouldn’t say that if that’s not something that your organisation works on day-to-day and embraces as part of their day-to-day delivery, that you should spend a lot of time sending your people on AI courses and how to construct these bots and everything. At that point I would bring in a specialist and say – okay Mr or Mrs Specialist – Please could you implement this on our website, give us some documentation and how to maintain it, and if we have problems with it in the future, we’ll call you again.
Jack: Cool, next question: “Should you control what people are learning from the centre? If not, how do you know you’ll get a return on investment?”
Scott: So I’m going to assume with this question that ‘from the centre’ means as in from the management or leadership team of the organisation. So there is a level of control you need to exercise, because if you just let people run around learning, you have no control over what it is they’re learning, right? So when it comes to our structured learning tracks for example, we’ve got the Technology track, which is designed to help people who aren’t developers to understand how that process works. It would be foolish of us to send senior developers on that track, because they know those things, in fact it’s senior developers presenting. So there is a level of collaboration and decision-making that happens between the People team and the people who are going on these learning tracks, to assess and understand what the mostmuseful one for them would be. Similarly, for the developer tracks, should you be learning TDD or should you be learning React, or should you be learning C Sharp? Well, let’s assess what you do in the business day-to-day, and see where you’re struggling, and see if one of these things really would help you. So there is some guidance, but at the end of the day for us, it does come down to individual choice of what would benefit you the most, just with a more guided approach from senior management.
Jack: Cool, right, next question: “Is it useful to measure what skills people have across your organisation to get a baseline?”
Scott: I think so, yes. When you think about that capacity and capability assessment step in this process – if you’re looking to upskill your teams, would be great to know “well we’re upskilling in ‘Skill A’ – Well that’s available elsewhere in my organisation. That skillset is already there to be taught, right?
The thing I would caution on there is that I’ve seen this done a few times in the past. So, people go around and they understand everybody’s skills, and they understand what’s available in the various departments, they make a big list, everyone gets very excited, and then it never gets maintained. And so when you look at it in six months, it’s got people who no longer work for your organisation on it. So if you are going to perform those sorts of assessments, absolutely go ahead, but I would say make it someone’s responsibility to let’s say on a monthly or quarterly basis, keep that list up to date so that it’s relevant and doesn’t die away in a shared folder somewhere.
Jack: Awesome. Right, our next question is: “Have you ever found people stuck in their ways, who don’t want to do things in a new way?”
Scott: I found this often with developers – and I will happily bore you with war stories on that until the cows come home if you give me half a chance, so don’t get me too started on the subject – but I suspect this is a common problem, not only in the technical world. So I think this comes back to selling the idea of upskilling to your teams. So you’ve got this wonderful plan and you need to convince them that this is now a good idea. You need to be showing them that this plan is going to enable them to better do their day-to-day job, make their work life much easier because they have the skills to execute, and make it a happier place coming into work every day.
And this is something I’ve wondered about before – I’ve noticed that as adults we seem to lose our love for learning at some point – I don’t know whether it’s when you leave school, when you leave university, you kind of inherently learn on the job a bit but it’s not like a structured defined thing, and you tend to resist it a little bit. And I find that bringing these processes on in a non-‘Big Bang’ approach, so phased, iterative, small small changes day to day, is probably the best way to do it, because you slowly build up that love for learning. And I’m speaking from experience here, because I was resistant to it a couple of years ago and I’ve embraced it over the last few years, and it has transformed my skills and made my life
much more pleasant.
Jack: Lovely. I think we’ve got time for one last question: “When would you use an external training provider instead of doing training in-house?”
Scott: Let’s think… So maybe if you are lacking one of two things: If you don’t have the skills internally to upskill well. If you don’t have those skills you’re trying to learn internally to your organisation then you have no one to teach them, so at that point you need to start looking outward, whether it’s consultants, whether it’s actual training courses to teach your people those skills. And the second is: Okay, you’ve got the skills internally but the people who have them don’t have the capability or the capacity to actually teach them. Not everyone is a teacher. Just because you can code, doesn’t mean you can teach someone else to code, for example. And at that point, if you were finding resistance from those other teams to teach you, or you don’t feel like they necessarily have the capacity or the capability, don’t waste your time harassing them and waste their time. Start looking externally.
Once you’ve got those communities of practice set up – let’s say it goes that far and happy days – You need to get your people who are practising those things in those communities of practice reporting back to you, whether they are almost hitting a brick wall in terms of learning any further… I had this with personally with guitar recently, I couldn’t teach myself any more and I realised it was time for a teacher. So I went externally to get the skills I needed because I’d hit a wall where I could no longer learn anything on my own. And that’s something you need to keep an eye on if you are managing these communities of practice.
Jack: Brilliant. Well I think that’s all the time we have for questions, so I’m just going to start sharing my screen. I just want to start off with a massive thank you to Scott for taking the time to speak to us today, and even bigger thank you for everyone who’s attended this afternoon. As I mentioned at the start of the webinar, we will be sending out feedback Forms. They take a minute to fill out and it lets us know what topics you want to hear more about and what we can do to improve our future events, so it’s massively helpful.
Our next webinar is going to be on the 23rd of September. It’s going to be with Scott and it’s going to be around enhancing developer productivity in legacy codebases. Our next webinar after that will be on the 30th of September. It’ll be delivering a user-centred NHS virtual visit service during COVID. The speakers are going to be Adam Chrimes, a Senior Developer at NHS Digital; our very own Jessica Nichols, who is a Senior Delivery Manager here at Made Tech; and Ian Roddis, the Deputy CDIO at Kettering General Hospital NHS Foundation. I should also mention that both of these events are going to be part of the Leeds Digital Festival.
Also, if you haven’t downloaded your copy already, or if you just want to do a little bit more reading up on what we’ve been discussing here today, our copy of “Building High Performance Agile Teams” is available on our website at the moment.
If you want to stay in touch or just find about out about all things Made Tech, we have our details of our socials up on the screen at the moment. Or if you didn’t get your questions answered by Scott today, or you just want to talk a bit more about what we discussed, Scott’s social details are up on the screen now.
And without much further ado I’m going to say have a lovely afternoon and thank you for joining us. Take care.
Back to the episode
