Scott Potter

What am I going to talk about today? To autonomy and beyond.

What is that? Well, you'll see the word autonomy come up in my slide deck, and you've probably seen it on several others today. One of the key things for the way I like to manage is to really, genuinely try to foster that kind of environment that brings about ownership behavior: people who can take responsibility.

So when they asked me for a title, when I was kind of panicking because I only had a morning to come up with something, this came into my head.

And I should also say that I'm just going to slightly change a bit of what I'm going to talk about. I've overheard some things, and I've listened to a lot of the other speeches, so I'm just going to slightly adapt it a little bit to maybe give you a bit of an insight into what was going on in my head as I was helping to... well, helping, but leading the transformation.

I think if I was out there, I think I would learn a lot potentially just from sometimes how it can feel quite isolated when you're trying to lead change.

So I'll just quickly take you through the company, how it was organized, a little bit about myself, talk about the business problem that we were trying to solve, how I went about that, and then the rather worrying-looking face is representing, "And what's next?" If you're a senior leader and you finally get to that key point where you've got autonomous teams, should you be worried? Have you put yourself out of a job? And then I'll try to package up a few key takeaways.

So hands up, who knows who News UK are?

Reasonable. Who knows who News International are?

Yeah. So News UK is the new name for News International. It's obviously very well known for various reasons, and not least because of its brands.

It's fair to say as well, I'm not selling anything, and I'm not even promoting them because I actually moved on just a couple of months ago. So it's really just to try and give my experiences of something that I did when I was there.

As you can see from the numbers there, it's not a massive company. And if we're talking about a lot of the large-scale changes, and "enterprise" kind of implies large scale, this actually isn't one of those stories where we're talking about tens of thousands or twenties of thousands of people. But most of the ones that have been successful have generally started quite small anyway, so hopefully it's going to be of some use to you.

And kind of starting at the end: last year, The Times and Sunday Times Group finally turned a profit for the first time in, I don't know, it could have been something like 50 years, something like that. So when we're going through some of the changes that we made, that was one of the key outcomes.

So Gene said, "Make sure you set the context." Other than obviously News UK having editorial, commercial, marketing companies, the technology organization was just divided into three key areas.

You've got a fairly traditional enterprise IT, and I don't like to really say it like that because they're great guys and quite forward-thinking. But in their responsibility for desktop support, running and maintaining a lot of the business-critical systems such as HR, billing, all those sorts of things.

And then in the middle here, DNA, delivery and architecture. I'm going to skim over that because it doesn't really fit into a holistic view. But they were effectively a change team with technology projects that they would do once, then hand off to somebody else. So we'll skim over them.

And then we have digital. I was in the digital division there. And the responsibility of that unit was to build... well, define what it should be, and build the digital products and the next generation, because that needs to be the future of News UK. Obviously, their main revenue is through print press, and we know the future of that.

So I headed up the engineering department within that division, and it had about 100 people. At its peak, through a couple of key agencies that we brought on, I was probably accountable for the output and the engineering of about 200 people. So again, not massive, but big enough when you want to try to make a change.

Again, just call out a couple of little things to understand a bit more about the company. In the last couple of years, The Times tablet app was the highest-grossing non-game app in the UK App Store. And The Sun Goals app was, as you can see there, the fifth. We're in the top five downloaded sports apps.

So the digital division. I thought, actually, when I was going to be here, there'd be a screen. I didn't realize how big it was going to be. So I thought I could point to things. So excuse me.

On the far right is a representation of... there was this tiny little delivery group. So there were three or four delivery coordinators where we had dependencies across deliveries and projects that we couldn't avoid.

Then the other slice there is representing product ownership, product strategy. And then the four boxes are the software engineering.

So the software engineering department was responsible for the definition, the development, the whole cradle to grave, and even decommissioning the apps, the websites, the backend services and tools that supported that, digital curation, access control systems, and identity. So there was a lot of different tech in there, and that's just to name just a few. And also what's been interesting hearing this is how people have been saying one size doesn't fit all. And I was able to experience that at a fairly small scale.

Okay, a little bit about myself so you know where I'm coming from.

Yeah, I started coding... well, actually before one of these, to be honest, but I couldn't find a picture of what I started coding on.

This guy here was still considered to be a genius, but then he hadn't released this by that time.

So my engineering career started at the same time as this guy made the World Wide Web public. He decided to launch Linux. And interestingly, the Internet of Things, that phrase was coined. So that's been around for quite a while.

So why do I mention that? Well, first and foremost, I am an engineer and I'm a techie, but I'm not really going to be talking about tech. So really just my own pride. I don't want you to think I'm not a techie in a room of techies.

I was with News UK for about four years, and I've recently joined Equal Experts in HMRC, where obviously Anthony Collard was talking this morning. So that's an interesting change.

Prior to that, I was at Xerox. And why is that relevant? Well, I was really fortunate to be there for quite a long time, and I wasn't just software engineering. I started off as a mechanical engineer, did electronics engineering and manufacturing, so just overall engineering. So many years ago, the ideas of experimenting and exploring, iterating, and then doing incremental deliveries, componentizing things, and having design for reuse and interfaces, it was everywhere. So I was just really quite lucky to be in that situation.

And then it sort of fostered my general curiosity to challenge the status quo with wherever I was, and then moving on to software meant that I challenged that. And it was around the mid-late '90s when lots of different people were challenging how things were being done. It wasn't just the people that had made a healthy living out of it from the Agile Manifesto and things like that. So I was quite young, but paving the way just then. So really, just take that from there as an engineer.

So the business problem. If we start back in February 2013, it was a fateful day in News. It got known as the Valentine's Day Massacre. And it was the launch of our new flagship product, which was actually The Times and Sunday Times tablet app, which was replacing a simpler version.

It was a disaster. The launch was an absolute disaster. There were bugs, defects. The backend system didn't quite work to support it because it was more than just an app. The user experience was awful.

We did stabilize the situation within a few weeks, but it was a bit of a wake-up call for some of the senior leadership at the time that there was a bit of a fundamental problem.

It's not fair to say that that disaster was representative of all of the teams. There were some reasonably good teams there, because myself and a couple of other peers had joined about 12 months beforehand as the start of a bit of a new phase, and we all had our own smaller teams. And the fruits of some of our work were starting to bear out then. But there was definitely a fundamental problem with the way we were organized and the culture that was there.

So the business problem I was trying to solve, they just said, "Scott, could you come build us a software engineering department, please? With a culture of quality, agile, based in London on incredibly average salaries. Oh, and for an infamous company."

So, quite carefully, I thought, "Yes, of course, I'll do that."

So I wanted to really just decompose what the problem was, what were they asking for? There were comments like, "We need a culture of quality, but you can't slow down. We still need to deliver at speed."

Now, we were delivering at speed, but it was just frantic, and it was often through short event horizons and short planning rather than a necessity to be able to move at pace.

So, okay, provide business agility. If you think about where the company were at, it genuinely needed that business agility. It needed to try different products. It needed to try digital products and work out where the revenue streams were and weren't. So it genuinely needed to be able to experiment and inspect and adapt.

So, to provide adaptive software development, which supports greater business agility.

Now, as a starter for 10, in my mind, I was thinking, "Well, okay, what is it I actually need to do? What can I demonstrate?" Because to be honest, I'm not sure people really know what it is that they want.

So if I can help to increase cash flow, if I can increase the adaptability and agility so they can change their mind, if we can try new things out quite quickly, successfully, without big failures. And from my perspective, it wasn't necessarily what was asked for, but taking Agile principles, and obviously we're talking about Agile and DevOps, and I'll come on to bringing them together shortly. But you also know if you do it right, you can substantially reduce project risks. So we know what the practices are to do that.

Is that quite small? Can you read it?

But we know that we can increase cash flow by releasing frequently and often and with good quality. We know that we've got practices such as extreme programming, frameworks such as Scrum. We've got technology and tools that a lot of people have been talking about today as well. And we know that bringing people together is a good way of being able to increase adaptability so we don't have these big handoffs and it's not all slow.

And of course, if we really want to genuinely reduce project risks or product incremental builds, then when we say we're done on something, we definitely need to be done. We can't be having integration issues or not really in production at a later point.

And of course, people are going to do this. So I added to my own list: we need a vibrant culture because we need motivated staff.

And I'll be perfectly honest, that wasn't really a working environment where you're going to get the best people and feel motivated. It was frantic, and I think the technology was great. I think that's why a lot of people were there. They were doing a lot of cutting-edge stuff at the time, which might surprise some people.

So this was really just a remit to myself.

So now we come to: how do we start to build this? And as I said at the beginning, one of the things I hopefully want to try to call out a little bit is what was going on in my mind.

I'm not a career person. I probably should've said a bit earlier. So when I got... I think I get asked. I had to apply, obviously. When I chose to take over the department, and it was actually a merger of two or three different departments, that was quite a big step for me because I was quite happy just having my little team doing things quite nicely.

But it was me and a couple of peers. The thought of somebody else coming in, and yet more change of direction, yet different ideas and different views. We had a chat, and everyone was quite comfortable for me to step up and try and take it on.

And the reason I mention that is I think a lot of the talks here have been, "This is what we've achieved," and I think it's really inspiring and it's great. But to me, it felt like there was a bit of a support network or there was quite a big team doing it, because they're massive changes that have been brought around.

I had the support of my immediate director and the CIO. My director knew what success looked like, what good looked like. My CIO knew something was wrong, and he had the trust in me to do it. But it did feel quite isolated and quite individual when I first set about it.

So I think bringing the Agile and DevOps mindset together. You see my background is leading Agile, but there's always lots of debates around, "Well, what's Agile? What's DevOps? Are there differences?"

So if we're bringing the right people together to do the right things and we're empowering them, then that's the key there.

So initiating change. What was important there? Well, I had to have quite a long, hard think about what am I bringing to this role and what's missing? Well, we can come and see what's missing.

So I'd already been doing a little bit of soul-searching. This is probably a different kind of talk to what you're expecting, isn't it?

I was doing a bit of soul-searching as to how I'd done well in the last 12 months with my team, because I was generally brought in for my engineering experience, and I hadn't done a great deal of engineering. I'd got involved, but I had a couple of good guys. And yeah, seemingly, it was going very well.

So I reverse-engineered what I thought the key things I had been focusing on, and I came up with these four key values.

So I was trying to nurture, develop, and grow people and give them some confidence. I was trying to inspire them to try different things and to innovate, and give them the safety net and the confidence to do so. That's focusing on the environment I was trying to create.

And I value engineering a solution rather than just cobbling something together: thinking about it, going through the right problem-solving process. It can still be very quick, but it's considered.

And funnily enough, I value delivery.

People say, "Are they really values?" Because people like values such as trust, and yeah, they're all great, but to me, I value those things. I value those in balance as well. So I value trying to do things the right way, and I value delivering and delivering an engineered solution.

So that's what I came up with myself. So that was a reminder to me of what had worked and therefore, in the frantic day-to-day life that the day was, just to be able to be mindful of it.

This was in the spring, soon after I took over the role, and started to talk to my immediate managers and different people about these types of things so they could also be mindful of it.

And then in the summer, because we were very much in a holding pattern for a couple of months, as we had a few key roles we needed to recruit into. We had a couple of massive deliveries we were in the middle of as well.

So in the summer, what I did was to take each of the teams off, just for a day, an offsite. And amongst other activities and things that we were doing, I asked them, "What do you want to be? What do you want to become? And what do you want to be recognized for?"

And they called out different things. We had some games around it, and then at a later point, I played it back to them. And that helped.

So it wasn't entirely accidental, but if I was to draw up my nice model now, you'd think, "Oh, he just got a model out of a book and used it." What I'll get onto in a minute is how my thinking evolved and how I built my own model primarily to help me.

So that was the first step of them really envisioning what it is they wanted to be and coming together around their first common goal, their first common purpose. So it was simply they wanted to become outstanding. But what did outstanding mean? And they gave some examples of what those things were. And it's an identity. It's a collective identity.

And then throughout those first few months, just simply trying to lead by example. What is it to be a professional engineer? So start to let people know what it is that I would expect a professional engineer, software developer, but an engineer to be, and how you'd expect them to behave.

Sorry, forgot where I was.

So by October that year, so we've already hit six months, but it was a slow-turning oil tanker because there were so many other things in play. But by October that year, I'd reorganized into the four groups that you saw there.

And the three key things were to make sure that each team were fundamentally aligned to a real set of users. We talk about bringing people together, and that's one of the key things. And every team was cross-functional and as autonomous and self-sufficient as possible.

So what that actually meant for me is when I inherited and took over a merger of two or three different groups, one of them was a standard software development, software engineering team. But then there was these shared tools, shared infrastructure, and even the QA, even though they were in Scrum teams, were managed by a different head.

So I brought that together. And when we talk about cross-functional teams, we're all on Amazon AWS. So we were designing and deploying all of those stacks as well. We were doing our own tooling within the different teams. That might ring alarm bells for you as to some diversity, but we'll mention that later.

So when I was talking with Gene, he said, "Well, again, just summarize how it is that you went about it." It was a bit of an evolution process.

So one of the things here was phase one: stabilize the situation. We had people join News not for a career, but just as a job.

So I'll just do another hands up if I can. Hands up, who's London-based?

It's probably not a big surprise seeing that we're in London now, but most of you.

So I think London's got, it's a bit of a... it's a double-edged sword. I think we get some great people because people can move around, there's good opportunities. But I think at the same time, people do move around quite quickly.

And if you're talking about bringing about a cultural change, how do you do that when culture is really people and how they behave and what they believe in? How do you do that when people are constantly changing and turning?

If you've got one in place, I think you can probably maintain it, but getting one in place was difficult.

So trying to stabilize things, stop people moving around too much, get people to want to at least stay for a while and not move on. Recruit the right people, not rush that, and grow core competencies. We can't become good or great if we're not focusing on the basics.

So I'll talk about the engineering model in a minute. And retaining key staff. There's so many things that I could be doing, that they were things that I just focused on.

And then after that, then I can think about how we increase productivity. We strive for proper engineering excellence. And the other key thing is to provide great careers. To get that degree of stability and to stop people constantly turning around, to get a culture that can really stick, I needed people to want to come and work for us, with us, and want to stay.

So I did a lot around training and development programs and all those other types of things that if you worked in a good place, that you would expect and you would understand.

And the other thing is I wanted it to become a hub, a place where if you're good or you're great, you can come to and know that you're working with great people. So that was part of the long game.

This is the engineering excellence model. Now, I'm very conscious of time, so I'm going to skip through a couple of bits, but this is probably one of the key things.

When people show you models, it's often, well, they're trying to sell something, or they're trying to do their consulting. This was very much for me to be mindful in the frantic days, and very much a communication tool also for me to be able to talk to my managers and actually everybody. This was a way of me trying to have a holistic view but trying to improve.

So you can see already where some of it stemmed from, where you're starting at the base. You might recognize it as a model of the logical levels in NLP, and it's about individual, it's about self. And I'm reapplying some of the principles to a collective.

I'll just focus on the first lower three before we go all the way up.

But it's obviously important to have a vision, know where you're going, and these are words that you hear all the time. But it needed to be a vision that meant something and something where they wanted to come to.

And by that point, everybody there knew that their colleagues wanted to become great and outstanding and wanted to improve. And if they didn't, because let's face it, not everybody does. They can just come in to a nice job, get paid, and go home. If they didn't, then they knew that change was inevitable, and they knew that actually it was their colleagues and peers that wanted better. It wasn't just me. And I think that's a subtle but important thing that I was trying to do.

The values that I spoke about, they're genuinely valuable to me. I wasn't going to sacrifice anything. And the way that those four come about is I don't need to sacrifice anything because I can focus on delivering. But if I'm focused on just delivering too much, that's going to peter out if I'm not focused on nurturing and inspiring people, or we're not engineering things in the right way.

Capabilities and behaviors, I think, is where we get more into this. We can think about DevOps as well.

So capabilities, we need to be able to do these things. And then the behaviors are, I could be the greatest technical person in the world, but if I can't communicate with my peers and I'm sitting in the corner, working away, I can never become something that's greater than the sum of my parts, which is what great teams are about. So behaviors and capabilities were really important.

And I'll break up the capabilities. I wanted to make sure, again, a holistic view. And when I talk about technical agility and organizational agility, you could replace agility for excellence and the other things you want to strive for. I think you could probably be technically excellent and not necessarily be agile because you haven't tried to focus on the right things.

So technical agility is, again, talking about patterns, architectures, frameworks, things that allow you to adapt very, very quickly and safely. The tooling around it allows you to do it. I promised I wouldn't even use the word Docker, but that would probably be where that would fit in.

So organizational agility can be micro. It can be how people organize themselves, or it can be at a large scale. But one thing we do know is you could have organizations in place which can certainly hinder your ability to be agile. How you organize to make sure you can become agile, well, that's going to be different depending on where you are.

Process agility, I'm running out of time, so you can think about basic Scrum. We could think about very, very lean principles, only do what you need to do.

And personal agility, I think, is the one thing I was hoping to try to get onto a little bit towards the end. So personal agility for me is the individual's skills to be able to interact and to be able to take responsibility. And I think you need to be concentrating on all of those areas.

And on the behavior side of it, we mentioned motivation. You need to have motivated people. That's going to derive a lot of key behaviors.

This got called out actually in the Barclays talk in a slightly different way. But it's if you've got people that have a clear sense of purpose, or relatedness as it's sometimes called, and they have the right degree of autonomy, and they have that opportunity to grow and develop, sometimes it's called mastery, then generally they're the good ingredients. If you've got one of those missing, you're running a risk of not having motivated staff.

So then when we think about, "So what is DevOps?" then if you approach DevOps from the DevOps way and DevOps side, then you're likely to be considering all four of these things. And if you're not considering all four of those things, you might have a little bit of a bumpy ride where it might not stick.

So although I was very mindful and very much aware of DevOps, I wasn't coming at my transformation with DevOps as the goal. I was coming at it from a slightly different perspective because that's just what my organization needed.

I think one of the key things is by focusing, for me, on those four things, I definitely had the right ingredients in place to then be able to strive for DevOps, with it more around the operations side.

That's a busy slide. I'm not going to talk through that.

But one of the things I do want to call out: this was some months in. That was the first time I even used the term DevOps inside the organization, because that wasn't something I wanted... didn't seem to be necessarily thinking about, which is interesting.

We had an operations team in place 24/7, and they were a great bunch of guys, but they demonstrated all of the behaviors and all of the processes that you would refer to as being in a traditional organization. And it wasn't that they didn't know better, but it's the fact that they'd been left holding the baby so many times before.

Before I'd gone there to News, products were built with project teams funded for one. "There you go, hand it over." And then the team would literally disappear. So the poor operations guys, they were literally left holding these things.

So the one thing I did want to call out, actually, was one of the things that really came through by trying to get not just cross-functional teams because you've got all the right disciplines in place, but genuinely the T-shaped people, where you've got lots of cross-functional individuals as well, is when you're talking about your infrastructure being software because you're in the cloud.

We learned very quickly that most of the people that were pioneering in AWS didn't necessarily have those rounded software engineering skills to actually make nice, cohesive, decoupled software items themselves.

So we found just as much the fact that having the people embedded in the teams allowed the teams to be autonomous and build what it was that they needed to do. But actually, the cloud-based infrastructure was much more nicely defined and engineered than if we'd had it done maybe by a separate team, or even by the same team, but just an individual within the team doing their own thing and not having it peer-reviewed or not working through that way.

That is a very busy slide, isn't it?

So if DevOps is partly to do with bringing the right people together, then successful DevOps has got to be partly to do with helping those people to succeed together.

And I have heard other people talking about high-performing teams, and it was one of my key focuses. What do you need to have in place to help a team to become a high-performing team?

I think one of the things generally is the first thing there is to have a self-organizing team. So what happens when you take a manager away? Do they instantly gel? Do they instantly come together and start working wonderfully? Sometimes, but not always. I could go on about England-Iceland the other night, but we won't go down that route.

So again, little list from myself. Need to have a common goal. Will we get that through Scrum, or we get it through having other visions? DevOps, having people aligned to real value or real products. So you can generally have that, but you need to make sure that it is clear and crisp and you're organized in a way that supports that.

One of the other things is the high standards and expectations, and that's of the individuals themselves. They have to have genuinely high standards. They have to be pushing themselves and never really be quite happy or content with what it is that they're doing.

And the expectations of one another. So they need to be able to hold each other accountable and expect more of other people, and help others, help their teammates to be able to grow and develop as well.

The ability to resolve conflict, I'm going to sacrifice a bit later on just to briefly mention this.

This is when I was at Xerox, actually. This is one of the key things that we were talking through on the Black Belt, which was an 18-month program. They said there was a key bit of research done, and if you looked at all of the dating websites and the algorithms to see how well they could match and pair people up, and you looked at how successful they were in the longevity of a relationship versus simply looking at a couple's ability to have conflict, because that's important, to have that debate and conflict, but to resolve it, the latter was by far the most successful at predicting the future success of that relationship.

So it kind of goes without saying that you need to have that ability in a team.

I'm not going to go into that because I am running out of time. I'm just going to skip over that as well. I said I was going to change it a little bit, didn't I?

And I tell people they shouldn't be scared to be agile. I was petrified when I came out here knowing I'd changed it so much.

People always say, "What did you achieve?" Busy slide again.

I deliberately avoided bringing up loads of stats about all the wonderful things. I don't know why. I just chose not to do it this time.

One couple of things I want to call out there is, I knew that if I saw certain things in place... Now, some are reasonably measurable, but I think you know if these things aren't in place. That's the important thing. Are they in place, or you know when they're not?

If these things were in place and I could see them, then we had a good chance of succeeding. If these things weren't in place, then it was going to make things incredibly difficult to succeed.

So empowered teams, you can read for yourself. The close collaboration at the top is making sure that the people that were the problem solvers actually got to grips with the problem, and they weren't just given some kind of solution or some kind of outcome that the company needed, and they were fully in that. So they could also challenge it, but they were bought into the reasons why it was needed.

And obviously, we're at a DevOps event. I shouldn't go through the whole presentation without mentioning microservice architectures. But we did have monoliths, and we did break them down gently, and we had lots of new products that we were able to apply that from the beginning.

I guess this is the "and beyond" bit from the "To Autonomy and Beyond." Yeah, don't be scared about putting yourself out of a job, he says after leaving his job a couple months ago.

So as a leader, what role do I play if and when you get to this position where you've got these autonomous teams?

Before I get into that, I'll just pause. The final state for us was that we still had this 24/7 ops team in place. They sat next to us, and they always did. We were talking with them all the time.

So if you're talking about DevOps, so you're talking about fully co-located teams. We still had this degree of separation. But could we go to production easily and quickly when we wanted to? Yeah, we could.

Could we choose more technologies that we wanted to because they knew that we'd be around to pick things up? Yeah, we could.

Were we also able to go to production with the understanding that, yeah, we'll support it? We'll support it. We don't need to jump through all of these hoops to show that it meets all of these operability needs. We know we need to get to market. We're prepared to support it for a while.

So it was a hybrid model, and again, it's getting to the essence of what DevOps is about.

So what now? What can you do?

I think if you're in a position where you're overseeing these things, you can definitely see things that maybe others can't. That's partly because you're looking and other people are focusing on different things.

If you've allowed that wide degree of autonomy, you're going to see different teams doing things in different ways. Or maybe see teams doing things the same way and one's working and one isn't. So you can start to look at those positive deviations and help other teams maybe learn from one another.

And that's partly to do... in fact, there's a next thing here.

They're not nice problems to have. Now, this isn't a nice problem, but one of the things that started to happen when we got to fully independent teams, and that's not to say they weren't set up to be fairly independent. They just didn't have the mentality. They didn't have the environment to genuinely take that on.

Fully independent teams means they need to talk less to other teams. So you give me that. Sorry. So yes, neither there.

Fully independent teams don't have to talk to other teams, so you suddenly get siloing again. That's one of the key things.

And the other thing is, don't worry too much about diversification of tooling or processes. Okay, it's easy for me to say if you're talking about tens of thousands, but if you think about evolution, natural selection, there is diversification, and then the weak ones die out.

So allowing things to diversify, but making sure that different teams and groups and people come together, they can learn from one another and work out what worked.

I did say you'd have to hurry me up, didn't I?

So I shall skip over all of these things to say beware of the fads in our industry. I was going to talk to you about personal agility, but I'll mention you on YouTube for that.

Look at all the stuff I missed.

Yeah, that's me.

I think that was a key thing for me. That was really mindful and actually worked for my managers, was the engineering excellence model. How does that work for DevOps? Pendulum and the stuff I didn't cover.

So I do apologize. Thank you very much.