Gareth Rushgrove

I'm going to go pretty quickly, especially to start with, because I've got lots to cover, and apparently I've only got half an hour or 25 minutes, depending on what Gene said.

So I'm Gareth Rushgrove. I'm `garethr` pretty much everywhere on the internet. Apparently someone thinks I look like this. And I work for Puppet. We've got a booth downstairs in the hall, so do come and see us. I'm not going to talk really about automation, but if you want to talk about configuration management and automation stuff later, I'm around.

What I am going to talk about is my time in government and a bunch of stories from that time.

A little bit of a backstory. A lot of people will have heard some of this anyway. But I became a civil servant about six years ago, something crazy like that. So the Government Digital Service, that lots of people have heard of, the GOV.UK project, that lots of people have heard of. I was there before any of those had those names. I was about the 10th person, 15th person into that crazy group of people that became GDS.

GDS is the Government Digital Service, and it's still going strong. I think there's at least one person in the room who works there at the moment. I think I spotted him back there somewhere. It's basically a unit of the Cabinet Office. It's responsible for a lot of the controls, a lot of money, a lot of how government does IT. It also has a bunch of people building stuff.

And I did a bit of everything, a nearly typical early-stage startup story, just I was inside government. I started there building a bunch of stuff, writing a bunch of code. I was the person out of the first batch of people saying, "If we're going to do this for real in a regulated environment, if we're going to be the biggest website in the UK government, there's loads of infrastructure and operations and information security work to do."

And my colleague at the time said, "Okay, you do that then."

I pointed out that that was probably more work than one person.

He said, "I know. Go find a bunch of people, hire a bunch of people, make a team, run that."

I did that for a while. I then spent probably the next couple of years, probably easiest understood as doing internal consulting for government. I was a civil servant. I worked for the Cabinet Office, but I helped a bunch of different departments on their IT transformation journeys. And sometimes I was the stick and sometimes I was the carrot, and sometimes none of us knew what was going on. And formally, I was a technical architect. I had a fancy job title. I'll come on to maybe that later.

I do want to say I'm no longer a civil servant, so some of this might be out of date. The stories will have undoubtedly got better, but hopefully they'll be familiar for people in other similarly messy organizations. But I do want to say shout-out to anyone who is a civil servant, because everyone should do that.

This talk is all about communication. It's about language, and it's about silos, and I'm going to try and draw a few things out. I'm going to try to do that by telling some stories, picking on specific bits, quoting some people out of context, and tying that back to languages. I want to talk about stereotypes as well. And I'm going to try to scatter throughout just some tips, things that you can do in your organizations, and hopefully there'll be something for everyone.

So first thing I want to talk about is language. And I want to start that off by saying: appreciate that you're in a silo.

I guess people talking about DevOps often talk about silos. But then actually, the people at the DevOps events nearly invariably think of themselves as outside that. "Oh, that's not me. That's them. I'm trying to bridge these silos or break these silos down."

And I think it's important to realize that that's nearly never quite true, or at least it's never true 100% in any direction.

And so I'm going to do some tests. I don't think we've got time to do loads of call-out stuff. But you see words like this: containers and scrum and serverless and cloud. And some people are probably thinking like, "Yep, that's my tribe. That's who I align with." And I'd say that's probably a bunch of developers, or it might be more people who are in a delivery organization or a digital organization, depending on what words you're using. But definitely beginning with a D, you're hearing those words all the time.

Some of the rest of you are probably more familiar with words like this. There's some people chuckling along. You're talking about COBIT and capacity management and configuration management and CABs. You probably are more aligned with an IT silo.

For the security people in the room, you probably talk about cyber and kill chains and APTs.

And there's a prize if anyone can tell me what all of these are. There's an even bigger prize if that person's not from government.

And some of them, people are sort of nodding, smiling, looking ahead. I think it's very clear that we build up languages around different disciplines. I've picked four here. You could probably just keep going.

We build up lingo: the language and speech, especially the jargon, slang, or argot of a particular field, group, or individual.

Your organization is composed of particular fields, particular groups, particular individuals, and they're all bringing their own language. And it becomes lingo, it becomes jargon, it becomes a barrier to entry.

And one of the points I want to make is that in a large organization in particular, that language, that lingo, acts as a barrier to entry to those communities.

If I want to go talk to the security group in my organization and I don't know those words, or if I want to talk to central IT, I want to talk to the CIO head office, then without an understanding of the words, without an understanding of the context, I don't need to be a COBIT expert, but if I don't know what it is, I'm probably going to get laughed at and pushed out and not be able to make my point, not be able to get my job done, whatever it was.

Because those language differences reinforce the silos. They don't just prevent you getting into them. They reinforce that fact that you're not part of that crowd, and so you start doing things yourself. A lot of things like shadow IT can become the fact that, well, it was easier to do it myself than have the people responsible for it do it for me. Language is part of putting up those barriers to making that the case.

So first tips, and I'll scatter these throughout. Have a go in your organization of identifying words that are only in use in one bit of it. It's really super interesting, and I think what you'll be able to observe is you'll be able to find the sort of seams between your organization. You'll be able to find silos in a way that's not just as simple as your organizational chart.

One area that I did a bunch of work in inside government, I said I ended up being one of the first people into GDS that really sort of focused on infrastructure and operations. I did a whole bunch of work around, I guess, in between and on both sides at different times, the agile software development methodologies and more traditional service management inside a large organization.

Within GDS, to start with, and for the people that have seen the material, seen the onboarding stuff, seen the website, seen what people from GDS have and do talk about: especially at the time, we definitely talked a lot about design. We talked about user research. We talked about agile and open source. And a lot of that was fundamentally because they were very new to government.

We weren't the first people to doing them, but we did have a podium, and we were doing them all together, and that was something we were trying to get government to do. We talked a lot about the discovery process. We talked a lot about doing alphas and betas, doing small things quickly on small budgets to demonstrate that there really was a user problem, and we knew what the solution might look like. We talked a lot about that, and you'll see that language throughout all the GDS stuff over the past five years.

We hired a lot of software developers, fundamentally because actually government employed very few. It used a lot, but it employed very few, and we talked a lot about that.

I think in hindsight, and to some extent not necessarily as a criticism, we didn't talk about operations. We didn't talk about the infrastructure or running things. To some extent, to start with, that was because we weren't running anything.

Ultimately, GDS was a brand-new organization within the Cabinet Office. We were created to do a number of different jobs, but we weren't really running anything to begin with, not in a way that we wanted to espouse to the rest of government.

But that had a knock-on effect. And one of the things I'd say is when you're communicating, especially if you're part of a transformation effort within your organization, don't just communicate and don't just talk about the things that you're trying to change. Talk about everything that you feel is part of that. Talk about the things that maybe are already being done well, as well as the things you're actually working on today, and talk about the things you're going to want to be changing later, not just the things you want to change tomorrow.

So one of the things was really that words carry a weight of context, of past experiences and other organizations. So people make assumptions about the things that you're not talking about. And ultimately, those assumptions are going to be different for different people, different organizations, different times.

And so unless you talk about everything, you risk people getting the bit you're telling them, but assuming things about the things you're not.

An example of this was picking on one of my ex-colleagues. This was very early in GDS, sort of I guess 50 people, 40 people, whatever. So I was there from, like you say, 10 to about 700, so quite a growth. But I think this was around launching the beta of GOV.UK, and one of my colleagues, quite senior colleague at the time, suddenly we're sort of like, we were going to go live, and he was like, "Will the release work?"

And to an extent, I was like, "That question makes no sense whatsoever." And I actually disappeared, checked something, came back, and said, "Yes, it's going to work. We've done it more than 1,000 times now. I'm totally confident it works now."

And the thing was, a release had become something that I was responsible for, but ultimately, we were doing it so often, it was just background. It was just happening every day, all the time. It wasn't a big deal.

The person asking the question, although they'd been actually fundamentally part of that team, they'd not really got into the details to that level. And their background was from an organization where releases were something that you did everything to avoid. When they happened, they always went wrong, and then you went into a big meeting and cried a lot, and then you tried to avoid doing it again.

And it's one word, and we had fundamentally different views on it.

One of the observations, I guess, in hindsight, was early members of GDS were from media, startups, technology backgrounds. And one of the things that became clear as we moved from being agitators to adopting practices that were required by government mandate, by legislation, by whatever assurance mechanisms were in place across government that affected everyone, was things like the formal language of service management was totally unfamiliar to most people within the GDS organization.

The comment at the bottom is, which is ironic because ITIL was a creation of the UK government originally. But obviously then, generationally, these people had joined and capitalized capital letters and so on. Service management was not something that the GDS people, the language they got. But it was familiar to government.

But one of the things that was also true was, but the practices that we now obviously align with DevOps, that really are addressing the problems that service management is all about, were just second nature. Of course, we were doing continuous delivery and deployment. Of course, we were using automated configuration management tools. Of course, we were doing these things.

And ultimately, that's probably more true of organizations today than it was five or six years ago. But for us, at that moment in time, this was second nature. But obviously, that was totally different to how those problems had been solved previously in government.

So one of the things, if you're going through a transformation, is realizing that you'll have different types of people, probably as part of that, that maybe your organization has never had. And even if it's just a generational shift, that brings with it this sort of, people bring their own languages, their own assumptions about what things are.

A good example of that is one of the terms I use there around configuration management. And someone's having flashbacks at the front there.

And as part of GDS, as part of GOV.UK, we had a very robust configuration management strategy. And what I was doing later as part of the more consultative stuff was wandering around government. And I remember this conversation, I won't name the department, but someone said to me, "Well, we canceled our configuration management effort because we couldn't keep the spreadsheet up to date."

They'd spent an awful lot of money. They'd spent a lot of time, and fundamentally, they couldn't keep that spreadsheet up to date, and so they just gave up. The point they gave up was when the recommendation came back from the team running that project that instead of changing everything every quarter, if they changed everything every six months, they reckoned they could keep the spreadsheet up to date.

And then at that point, their organization was like, "Honestly, maybe the spreadsheet can stay out of date, and we'll ship faster. If it's one or the other, we know what we're doing."

And I remember just simply being able to show what we were doing there, and because, again, it was second nature to myself and people who'd set up GOV.UK, set up GDS. Well, we knew the state of our infrastructure all the time on a several orders of magnitude difference that was like, "Well, no, that's not possible. How did you do that?"

And ultimately, we weren't doing anything new or novel. We weren't inventing technology here. We were simply using things that existed in a different context. But it was all the same word. It was all the same problem. It was configuration management.

And again, overlapping words from different tribes, different generations, are a great place to start collaboration. And from that conversation, it was able to say, "Well, oh, yeah, no, we have a shared problem. But actually, we solved it and you didn't, but we solved it in a generationally different way."

And finding overlapping words often means you can have a conversation that is otherwise difficult between those different silos, different groups, different languages.

I'll grab some water.

One of the other areas that I find super interesting when it comes to communication, when it comes to silos, is that of stereotypes. Because I'd say a lack of personal relationships, and sometimes that is caused by language, sometimes it's caused by all sorts of other things, leads to stereotypes. It leads to caricatures. It leads to, "Oh, and the developer," not Bob, who works over there. And that makes it easier to distance yourself and make fun of, and go your own way, and that's what we're trying to resist with that resistance to silos.

A stereotype, I think most people are familiar, is a widely held but fixed and oversimplified version of the person.

But coming back to our four groups earlier, we had the IT group, the developer delivery digital side of things, maybe the security group, maybe the government group. I'll give people a few seconds to work out which ones they think it is.

Who doesn't have a digital or a developer group that wants to use shiny new technology?

And anyone familiar with government will be familiar with the incredibly hierarchical structures leading to weird things like people saying before you've done anything with them, "What grade are you?" And basically, it's a polite way of asking inside a government context whether they have to pay attention to you.

And can you imagine going into a business meeting and saying, "Oh, hi. Do I have to pay attention to anything you say or not?" That's impolite. Government has a polite way of saying it, which is still as crazy.

IT might be asking about buying a lot. Security will probably be saying no.

My guess is most people got all of those right. They are totally unfair. They're oversimplifications, but everyone probably got them right. Stereotypes are a way of us communicating that sort of, not quite right, but not quite not true information.

We often talk about organizational silos, like the org chart problem of, "Oh, we created a development group and an operations group, and they fight because we told them to do different things. Who'd have thought it?" I think that comes across in a number of the conversations earlier, and Jason's talk from Disney, for example.

But lots of silos are personal. People like creating groups around them or aligning themselves with a tribe. And a lot of the silos come from cross-cutting disciplines that are not just deeply organizationally structured. They're people.

A good example of this is the somewhat infamous Bastard Operator From Hell, the BOFH. And the definition on the internet is "a fictional rogue system administrator who takes out his anger on users and others who pester him with computer problems."

The emphasis on fictional is mine, because as far as I'm concerned, as an operator occasionally, these people totally exist. And I think a few people I've shown this to have been like, "Fictional? What?"

And again, it's a stereotype. Again, we're being unfair. And some people will align with this character more than against it, and it gives us something to form boundaries around, and resisting that is useful.

The reason I'm talking about stereotypes is because by being aware of them, you can use them to your advantage to break down the barriers that they cause and have caused in your organization.

Because if you're going in, as I was in a number of cases, from the... GDS was very much more aligned, because we talked about it more, the developer, digital side of things. A lot of what I did was actually going in to talk to departments' IT groups, often after some of my colleagues had been to see them and said crazy things.

But I was able to go in with the knowledge that actually they were going to perceive me as this crazy, young, trendy, fancy technology, agile developer, nothing to do with production problem. If I could go in and play on absolutely opposite of that stereotype, it made people think.

Part of that comes back to the language. Part of why I got interested in the topic of language was because in order to do my job, in order to break down that, use that reverse stereotype, I had to be able to speak their language at least as well as they did. I had to become a domain expert in the things they did.

One of those areas that I got very involved in while I was involved in government, and still do a little bit now, was security. And one of the things I want to talk a little bit about is, I guess, the power of experts, but also the problems with intermediaries in silos and organizations and change.

Because there's definitely, and it's not just me saying it, there is definitely a perception of security says no. The internet is littered with quotes like this and sort of, "In my experience, infosec teams say no and not why or suggesting alternatives. Not helping, it's just slowing change."

Again, I'm stereotyping, but this is a pretty commonly held stereotype.

Part of this I think comes down to expertise. Actually, the domain that we work in is incredibly broad. It requires a lot of expertise. And in lots of organizations, in lots of cases, we scale the finite amount of expertise with paper.

And I think security does this probably better or worse, depending on your viewpoint, than most other areas. It's the reams and reams of policy, often internal, often interpretive, as well as regulation, that come into information security work.

The issue there is that you will have some expertise, but you're trying to scale it via paper. And in order to do that, you need middlemen. You need intermediaries. You need someone to distribute the paper and be the at-the-coalface version of that paper, because no one has enough time to read it all.

And one of the things I'll say here is that you break this down by having access to the actual experts. And one of the things I particularly enjoyed at government was I had a totally unfair advantage when it came to the security side of things, because my security experts were GCHQ.

Not everyone will have the same go-to people in their organization, but you'd be surprised about having some. A large organization, obviously we heard from Barclays and Zurich and the like this morning, will have some very smart, very domain-specific experts. If you know who they are, you're not going to have to be the expert, but if you know where they are, you can often ask them.

So again, one of my stories from my time in government. GPG 13 was Good Practice Guide 13, for non-government people. Basically, a set of documents written not by people who wrote very well, on topics that they fundamentally understood, but communicated in a sort of not in a prescriptive manner, to a load of middlemen who then distributed the knowledge.

This turned into lots of policy wonk arguments between technical people and interpreters of the documents. They invariably went like this, and I said I'm totally unfairly paraphrasing here, but this definitely totally happened: "I think you'll find that you can't do that because of my interpretation of this wording in GPG 13."

Anyone who's had any sort of dealings with auditors has probably been through something like that. The difference here being the person saying this isn't actually the auditor. They don't get to decide anything. They're just interpreting a document from another expert.

My response would've been something like this: "Ah, oh, fair enough. But I think, let's have a different opinion. Let's ring Richard at GCHQ and see what he thinks." Well, because they wrote the document. They're the domain experts.

Invariably at that point, the middlemen will freak out. And in my experience, which is good fun, because invariably you get access to the expert. The expert may or may not agree with you, but you're bypassing this inertia in the middle.

Don't let the scarcity of expertise lead to unapproachable stereotypes. A lot of that wasn't that that intermediary couldn't actually also contact that person. They actually had an entire network which allowed them to contact the same people. They might not have the same personal relationships, but they could totally contact those people.

It was that, "Well, no, they're important. They're busy." They'd made themselves unapproachable, so the documents became tablets in stone interpreted by middlemen, and suddenly you have all sorts of knock-on effects.

Don't let scarcity of expertise. You will have experts. Make sure people know how to contact them directly. And I think that often helps break... It stops certain types of silos emerging in the first place.

One of the areas that we took advantage of a lot within GDS, and you see as a pattern in lots of organizations that have successfully adopted our various DevOps practices, is using code as a way of facilitating communication.

As a quick example of that: the dreaded incident severity conversation.

I'm sure lots of people have had that conversation where you get in a room with different stakeholders from different parts of the delivery organization, the running operation, the business parts of things, and you come up with arbitrary words and arbitrary meanings for things like, "Oh, well, no, I think that's a P1."

"Oh, I'm not sure."

"What about the matrix from our different suppliers?"

"Oh, well. Oh, they have a... Oh, excellent. They have a table."

"So did the other supplier."

"Oh, they're different."

"Oh, now we need a..."

Lots of people have been there. It's great fun.

Stage one of that meeting goes something like this: everyone thinks everything is critical. That's solved that. Everything is the most important. Any type of problem you can have is the most type of problem you can have. Job done. Obviously, that's not very useful.

So you convince people that that's not very useful. Stage two is basically, oh, yeah, actually, some things are less important, but anything to do with my service is completely important.

The issue here is it's all about semantics. It's all words. It's all language. Well, I mentioned critical and sev one and priority one. They're all just made up. They don't generally have a mapping to anything in the real world, apart from maybe support levels or money back. Having something that is much more in line with the actual running thing is more important.

So one of the things we did at GOV.UK that's still in use, as far as I know, was basically a whole series of high-level smoke tests. And these were just computer tests written at a very high level to test the entire system.

But one of the things we did was you could tag them. By default, they would run, and by default, they would alert people, but you could tag them in such a way that that was the discussion point. That was whether something would ultimately page someone, get someone out of bed, or whether it would trigger various different SLAs.

But it was in code. The actual test was aligned with the SLA, and suddenly all the conversation happened around in one place. Not some of it in a meeting, some of it in code, some of it on the system, some of it with this supplier or other. You're putting it all in one place. You're also avoiding the ambiguity of human language.

Language is lossy. Computer code can be buggy, can do the wrong thing, but it shouldn't be ambiguous. It's going to execute. It's going to do something. The computer is ultimately the arbiter of whether something is ambiguous or not.

There's loads of opportunities for taking this approach. The internet is scattered with different ideas. A few I picked out, and this was after I left GDS, but they did a bunch of work around acceptance testing for their content distribution network. And what's interesting here is that they can go to suppliers and say, "Well, are you conformant with our requirements?"

And their requirements are not a 100-page document that someone has to discern the tea leaves and work out what that means. It's a test suite you can run against your product and say, "Well, does it pass or not?" So it nearly impacting procurement and supplier selection via moving a bunch of that ambiguity into code.

BDD Security is a security tool for describing testing code. And Puppet, I mentioned I worked there, is for infrastructure management.

So I've got a few slides left. I think I'm over time, but I'll keep going.

Where possible, combine policy with implementation. Bring these things together. Don't have the ivory tower and the people who do stuff. It only ends in bad blood.

So concluding at the end: try and share language as much as possible in lots of different directions, not just between business units, but between different disciplines, different types of different organizations.

The more you can do that, the better, because sharing language makes shared tooling and processes easier. The more you're sharing tooling, the more you're sharing processes, the less you're spending on recreating those wheels in different parts of your organization. You also get advantages of being able to move between different parts of your organization much more seamlessly.

Again, all of these things are pushing down cost.

And if your organization has all those problems, it has all those silos, one of the best ways I found of starting to break them down is identify the different tribes, learn the language of one of them, and use that in order to change your organization.

So I was asked by Gene to put something like some of the... I think there's a tradition for DevOps Enterprise of having an ask. And one of the things that I haven't covered, and I don't know how to know, but I think is a great question for this community, is: I've talked about patterns to address silos in your organizations, because most of us work in organizations that exist. But what macro-organizational structures could we have in place that limit the emergence of those silos in the first place?

So with thinking about that, that's me done, and thank you for listening.