In our latest episode, Zoe Cunningham is joined by Tom Riley, Delivery Principal at Softwire.
Tom has overseen the successful delivery of numerous UK public sector digital projects, including the modernisation of the register to vote service, the cloud migration of the gender pay gap reporting service, and the replacement of the software underpinning the high-profile Feed-in-Tariff scheme.
In this wide-ranging chat with Zoe, he shares insights on how to keep abreast of a diverse portfolio of projects, how to ensure teams stay up-to-speed with the latest GDS and industry best practices, and why he sometimes prefers old-fashioned pen-and-paper, and face-to-face communication, over their modern digital alternatives.
Of course, no tech-related discussion at the moment would be complete without touching on artificial intelligence (AI), and Tom shares his thoughts on the opportunities and risks associated with AI in the unique context of government.
You can listen to the full podcast on this page, or wherever you get your podcasts, and read the full transcript below.
Digital Lighthouse is our industry expert mini-series on Softwire Techtalks; bringing you industry insights, opinions and news impacting the tech industry, from the people working within it. Follow us to never miss an episode on SoundCloud now: See all Digital Lighthouse episodes on SoundCloud
***
Transcript
[music]
Zoe Cunningham: Hello, and welcome to the Digital Lighthouse. I’m Zoe Cunningham. On the Digital Lighthouse, we get inspiration from tech leaders to help us shine a light through turbulent times. We believe that if you have a lighthouse, you can harness the power of the storm.
Today, I’m delighted to welcome Tom Riley, who is a Delivery Principal right here at Softwire. Tom, can I ask you to introduce yourself and tell us a bit about your role and your area of responsibility, I guess, at Softwire?
Tom Riley: Yes, that’s fine. As you say, my official job title is Delivery Principal. What that means is that I look after a range of our projects. Making sure that we have the right teams on those projects and that we understand what our customers want, and that our customers are getting the best-possible service they can from us.
Obviously, as part of that, making sure that Softwire are hitting their commercial goals for the project. Basically, I’m responsible for not only delivering the project, but making sure that we have everything in place to deliver it successfully. My particular area of focus is in the public sector. I’ve been focused on government projects for the last five years.
Zoe: OK, super. I’ve got all kinds of questions arising from this. Firstly, I was just going to ask, does that mean you’re on the hook if there are challenges with the project? Are you just assisting, and it’s someone else on the line if there’s a problem, or are you actually accountable for it?
Tom: Yes, I think the job of the Delivery Principal is to be accountable for the project. Both from being a point of escalation for the customer if they have any issues, or even just want to tell us that we’ve done a great job, and also from senior management at Softwire, on the hook for making sure that it succeeds from a commercial point of view and is achieving what Softwire wants from the project as well.
Zoe: You’ve been at Softwire for a very long time, haven’t you?
Tom: Yes, I have. I didn’t necessarily want to look this up, but I think it’s coming up to about 17 years now, which is a long time, now I think about it.
Zoe: [laughs] Congratulations. Also, it made me think that you mentioned focusing on government work for the last five years, but obviously, you’ve got a vast range of experience from before that as well. Are you able to sum up the differences or the particular challenges and flavour of working on projects for the government, compared to working on private sector clients?
Tom: From my point of view, it’s a bit of a different way of working. There’s a lot more focus on making sure that the users are consulted in what we’re doing. Typically, we are building public-facing services, for example, Register to vote, things along those lines. We need to make sure that they are as easy to use for people as they can be. Really making sure that we get feedback from a wide variety of users, and building that into the things that we are making. I think that’s a really interesting part of it: Accessibility and user research being at the heart of everything we do on these government projects.
Zoe: Yes, because I guess that the public is almost like the broadest category of users you can ever have. Even if you’re building a travel system, then it would still only be people who are looking to travel, which narrows it down a certain amount. Whereas the kind of services that I guess you’re working on are applicable for everyone in the country, and so it’s really important to make sure it doesn’t work for just one group of people.
Tom: Yes, that’s exactly right. As I see it, there’s two different sides to that. There’s making sure that we have spoken to users from all of the different categories, to understand what they’re trying to get out of it, and what their specific challenges might be when using that service. Then there’s making it technically accessible, so that people with accessibility needs can use it in a useful way. A lot of that is building off existing patterns that have been delivered by GDS, so we’re not reinventing the wheel every time there, but every service is different in some way, and [it’s about] making sure that those different bits are as easy to use as they can be.
Zoe: I like how you’ve summed it up, because I think if you’re in the kind of role that you’re in, you’re managing lots of different competing priorities at the same time. However, I think that the more you can sum up what the focus is, the easier it is to bring a team along with you. I really like that you’ve summed up the focus as “making the software easy to use”. Obviously, in reality, that encompasses a large number of different aspects. Is that right?
Tom: That’s right, yes. It encompasses technical build, so there are technical standards for accessibility, etcetera. It encompasses user research, as I touched on earlier, and it encompasses service design. That’s how you build the service, what questions you’re asking, what screens you’re presenting to users, and how to make them as easy as possible for people to navigate. Basically, [it’s about] matching their mental model of how these things work.
Then there’s also content design, and I think that’s actually a really interesting one. Years ago I would think, “Oh, the content is fine. Anyone can just write reasonable content. I can write sentences, therefore I could write content for a website.” But actually, there’s a real skill in making content that is understandable but still gets all the points across. I think often with these government services, you’re trying to get across some fairly nuanced legal positions based on legislation, etcetera. Trying to explain them in a simple way that can be understood by everyone, is actually surprisingly difficult.
Zoe: Yes. Perhaps another difference when working on a single product or service for a particular company, versus building for the government, as you already mentioned, [is that] you’re integrating with what is already a really large suite of products that’s for the end user. Ideally, you want them to see it as one system. No one likes having to go and use five different systems to get to something central from the government. How does that affect your work, the fact that you’ve got to, almost seamlessly, I guess, integrate with what’s already there?
Tom: A lot of this is about making it feel familiar to the user on the outside, even if it’s actually different on the inside. It’s not necessarily about what technology you use, it’s about making sure that the front end looks familiar. GDS, the Government Digital Service, have put a lot of time and effort into building components, etcetera, aimed for reuse across a lot of different services. When I say components, I mean a standard text box or a checkbox, or a way of displaying error messages. That means that you can just use their patterns, and it will instantly be familiar to anyone who has used any part of gov.uk.
I think that’s a really important part in making sure everyone has a consistent experience. You might build it in the backend. I’m not going to list all of the technologies, but we’ve built things in C#, we’ve built things in Node, and regardless of what we’ve used to build them, the front end has a very familiar feel, regardless of the underlying technology.
Zoe: Right, exactly, which is then about separating out what’s the best technology to build what you’re building. The user doesn’t need to know that, right?
Tom: Exactly. Also, the GDS don’t want to mandate that every service has to be built using the same technology, because that’s not going to help anyone. It would mean extra costs, I suspect, in some cases.
Zoe: Right, yes, and less flexibility.
Tom: Indeed.
Zoe: OK, let’s talk a bit more about how you do what you do. Obviously, in your role as a Delivery Principal, you are accountable across many different projects. You’re working with perhaps lots of different technologies, with lots of different people. How do you context-switch between the different things that you need to do, and do you maybe have a different version of yourself:[chuckles] this is this project Tom, [whereas] this is that project Tom?
Tom: I think in my case, I do do a lot of context-switching. The key thing that I’ve learned is that it’s not possible to know the exact detail of every single project if you’re going to have to jump across lots of different ones. As much as I would like to know exactly how things work, it’s just not feasible to do so. It’s about knowing what I need to know, if that makes sense. Understanding what I need to worry about, to make sure that a project can be delivered successfully. And that might be the happiness of the team. That might be how we’re progressing against the dates and milestones. That might be the levels of technical quality, etcetera. Obviously, there’s some common themes across a lot of projects, and exactly where you need to get to on all of them. It’s slightly different from project to project.
In terms of bringing a different version of myself, I try not to, personally. I try to act in the same way across all of my projects, I think. Obviously, you have different challenges. You may have different levels of customer satisfaction, for example, but I try to be open and friendly throughout, and aim to give a good impression of Softwire that way.
Zoe: Yes, fantastic. That feeds into what I was just about to ask, which is that, essentially, so much of your role, I guess, could be summed up as communication in one form or another, whether it’s written communication, verbal communication, communication with people working on teams within Softwire, communication working for clients. Is that something that you have had to focus on and learn, or is it something that actually comes quite naturally if you’re, say, thinking about the objectives?
Tom: I think that’s a really interesting question. I think that parts of it come quite naturally to me. I’ve always quite enjoyed writing, I’ve always quite enjoyed written communication, but I suspect I have a tendency to write in a way that is not as succinct as it could be. Part of it is you’re sending someone an email, they’re busy, you need to get your points across in a fairly concise way. What I try and do is write things in a way that I would naturally write them, and then have another look through it and see where I could cut some of the extraneous words out, which always upsets me a little bit because I quite enjoy having nice sentences and have to make them worse, but I can deal with that.
Obviously, I think another key part of communication is just deciding what communication method to use. I think it’s quite easy to write emails and similar, because you have a bit of time to sit back and think about the points you’re trying to get across, and do it that way. Often, the most effective way is actually just, in the old days, pick up the phone, or these days, start a Teams meeting or similar, because you can see how they’re reacting to things in real time that way. You can find out what impact your message is having at the time you’re delivering it, rather than reading an email in isolation and they go away and think about it and come back to you like that. You can actually find out a lot more and have more effective overall communication that way.
Zoe: Yes, and it’s an opportunity, isn’t it, to build some rapport and relationship in a way that’s easier with your team, because you’re in an office together and you see each other? That kind of distance you can get can really hamper a project if you’re not on the same page in terms of knowing what you’re delivering, and working towards the same ends.
Tom: That’s exactly right. I think we noticed that in particular during lockdown. I think we started a project during lockdown, and we never actually met the people we were working with in person. It did make it harder. I think we felt that we made slightly slower progress, as a result of not being able to work too closely with the team. I think there were days where we thought, “f we were all just sat in an office together, we could have talked through all of this and got to a solution.” I think it’s another one where again, over time, people have learned how to deal with this, and yes, I think we are now fully comfortable with working remotely, where we can.
Zoe: I suppose the other thing then, is because you’ve got this context-switching of, like, “Hold on, what am I doing? What’s my focus? What am I trying to achieve?” Then maintaining all these relationships with all these different people. Then you’ve also got almost a simpler challenge, but still, I think a big challenge for everyone in a senior role in any organisation, is how do you actually map out your time and make sure that you’re spending your time where it’s most effective? Have you got tools or processes that you use for that?
Tom: Obviously, I use my calendar to keep track of meetings, etcetera, which do take up a significant amount of time. What I aim to do is actually use a fairly basic process in terms of mapping out a week on a bit of paper, and just try to [set out] where I need to focus on these days. If I have some spare time, this is what I’m going to look at. Then, on a day-to-day basis, making a list of the things I want to do by the end of today, and ticking them off as I go.
Zoe: I suppose I started working in this era where suddenly everything was becoming digital. It was really exciting and there are such advantages of having your calendar online, and having these documents online you can share and edit remotely, and you can both edit the document. Then I feel over the last maybe five years or so, I’ve seen so much return to these kind of analog, I guess, type processes or essentially using pen and paper for things. Putting your card-walls on the wall, rather than online. I guess that’s the same kind of thing as with using pen and paper, is that it almost makes it different, doesn’t it? Everyone is drowning in electronic communication, and emails, and Slack messages, and so actually it makes it unique, and the source of truth for what you’re doing.
Tom: Yes, and I think the act of being able to step away for a minute and work out, “This is what I’m going to do on this day,” is actually really valuable. It gives you a little bit of time away from emails and instant messages to just sit down and think, “What are my goals for today? What do I want to achieve, and how am I going to get there?”
Zoe: OK. That’s really interesting looking at where you are, what you do, and what your responsibilities are. Something I always really like to ask people is, what did you have to do to get to where you are? If there are people who are listening to this conversation now, and they’re thinking, “Oh, that job sounds amazing.” Maybe they’re currently working in a development role or a project management role, and they’re thinking, “I would love to have this kind of executive-level [responsibility] looking across loads of projects.” What would you say are the key skills that you had to learn, or how did you have to develop? Your background is as a developer, right? What were the steps from there, and how did you grow your skillset?
Tom: Yes, so as you say, I started as a developer, moved into doing a little bit of tech leading, but for me, I then moved into project management or delivery management as we’d now describe it, on a range of projects, which I found quite interesting. I quite enjoyed the interactions with the customers, and I quite enjoyed trying to work out what they wanted, and lead the team towards delivering what they wanted, roughly speaking. I ended up doing that on a bigger and bigger scale,rying out different techniques on different projects, learning different ways of doing things.
I think a lot of my being able to provide support and governance to the teams is based on having tried out different things and knowing what works and what doesn’t in certain situations. I don’t have a one-size-fits-all approach here. It’s very much, “OK, so this project sounds a bit like this other project that I did about six years ago. What worked well then? How could we apply that to here?” To a certain degree, there’s getting experience of trying different techniques, etcetera, in delivery management, and being able to then support other delivery managers in making suggestions as to what they could use to improve their projects.
I also think, for technical projects, there is some advantage to having come from a technical background, because you know how developers work, you know the nature of the work, and you know that sometimes things will take longer than you said, and sometimes they’ll take less time than you said. I think having an understanding of why that is, is also quite valuable.
Zoe: I guess then understanding what can be done about it, and when something can be done about it, or like you say, learning what the different options are, so, how to deal with something unexpected.
Tom: Yes, indeed.
Zoe: I love your answer because, for me, it’s so similar to the agile development methodology. That actually, I feel we learn by doing a little bit, and seeing what happens, and then keeping doing what works and not doing what doesn’t work, and stopping and reviewing every so often, which is basically the agile development methodology. [laughs] I think that’s really cool at a meta-level.
What do you do to help other people on your teams develop themselves in the same way? Is there anything you consciously do as the leader of the team to help them get that same experience?
Tom: We touched on communication earlier. I think that’s a really important part of anyone who’s acting in a delivery management role. Try to help people with different ways of communicating things and different techniques that they could use. In particular, going back to what I said earlier, asking the question, “Could we just ring them about this?” As I say, people have a tendency to not want to do that, I think.
Zoe: [laughs] Yes.
Tom: Then there are some things which work better over email, and just having ideas. Again, people have helped me structure emails in the past, people have helped me on different ways of getting written communication [right]. Having gone through that process, being able to share that learning with other people, is really valuable too.
There’s then supporting them, as I mentioned, in different techniques, which is about understanding enough about the project to know what the challenges are, and being able to make constructive suggestions.
There’s also another side of it, which is, how can you help people think about what they haven’t thought about? This is about asking questions. It’s about asking the right questions so that people will think about things that they haven’t considered, or risks they haven’t worried about at that point. An obvious example might be, have we thought about how we’re actually going to release this thing to live? Obviously, in most cases, people will have thought about that, but it might be that, at the start of a project, we haven’t quite thought about that, but it might impact our overall approach. Just trying to ask enough questions to get people to think about things they might not have done, I think is a key part of it.
Zoe: Then going forwards they can learn how to ask themselves those questions.
Tom: Exactly. That’s why we give everyone small plastic docs to ask the questions too.
Zoe: Exactly, which there is an article about on our Insights page, if that’s not a concept you’re familiar with.
One of the factors that’s really important for your job is understanding the general technology landscape and what’s going on. There’s a lot of different information that you need to be up-to-date with and aware of. What do you do outside of just learning from what you’re doing on your project, to keep up-to-date with technological developments?
Tom: I think there’s a lot of really interesting blog posts etcetera to read about these things. I mentioned GDS earlier. They put out a series of blog posts, which cover a range of different topics and how they’re approaching things. That’s different departments publishing blogs on the GDS platform, but also the central GDS team, what they’re working on, and what their priorities are for the next few months. I think that can be a really interesting way of finding out how, within government, the technological landscape is changing. To give a concrete example of that, they’ve got a lot of work on the One Login programme at the moment, so having a single login for all government services that would need one.
I think it’s really interesting just to find out about that, what changes that might mean to other services, and what impact that might have in the future on things that we are developing.
I think in general, what I aim to do is, listen to podcasts – hopefully ones like this – and look out for interesting blogs and share them amongst our team. We do a good job in our team of sharing things they have read and found interesting. I’ll try and do the same, and it just means that everyone is expanding their knowledge as best they can.
Zoe: Fantastic. All right, let’s finish with the current hot topic, which is AI. How do you feel about using AI within the public sector and government projects? Is it a fantastic tool that’s going to help us do everything quicker and cheaper, or is it actually quite dangerous, particularly when you’re looking at all this kind of sensitive data and information, and how critical these services are for the general public?
Tom: Yes, it’s an interesting question. I think there’s two sides to this. I think the first is on the generative AI side, people might be looking at government services and are there ways I could make those more efficient, or easier for people to use, by using generative AI? I think there’s a certain reticence, and rightly so, on using tools like that, because once you are using something like that, you’re no longer necessarily in control of the advice that you’re giving to people. I think people come to a government website to get advice that they know is correct, and having the risk of that being slightly wrong, for whatever reason, is actually a major part, so I think correctly, that we need to be quite careful about thinking about replacing existing services, which we know are giving the correct advice, with a shortcut to doing that, because the downside of getting it wrong is very high.
I think the second half of this is then, are there ways we could improve how we deliver these services using AI tools? So AI code-generation, and similar tools. Again, I think it’s an interesting one for the reasons you described. A lot of the services that you work on are handling people’s personal information, or they’re storing sensitive data, etcetera, and therefore, need to have very high standards of security and code quality. For me, it’s not, “We would never do this,” but it’s, “If we do this, we need to make sure we have suitable processes in place to make sure that all the code is reviewed, that we’re entirely comfortable that any security flaws have been looked at,” and that kind of thing. I think it’s an interesting one. There are definitely efficiencies that could be had, but I wouldn’t want them to come at the expense of the security of the solutions.
Zoe: Yes, absolutely. I quite like what you’re describing there about essentially having a human accountable for any piece of code. That however it was generated, there is a person who has said, in the case of projects you are working on, “I, Tom Riley, am happy that this is code doing what it says it does, and it’s going to make the world better and not worse.”
Tom: Yes, I think you’ve summed it up nicely there.
[laughter]
Zoe: Thank you so much, Tom. It’s been fascinating just to get an insight into the day-to-day of how these large, complex projects work. We have got podcasts on quite a few of the topics we discussed today, [including] more podcasts on exactly how the government design their services, user[-centred] design and service design, so, please, do check out our other podcasts on Softwire Techtalks, which is available on SoundCloud, Spotify, and all other podcast apps. Thank you very much, Tom.
Tom: Thank you.
[music]
