Host Intro (Gene Kim)

Thank you, Peter.

So Ben Grinnell is one of the very few people who has attended every one of the 14 DevOps Enterprise Summits we've held since 2014. He was one of the founders of North Highland, a consulting firm they created 17 years ago, a change and transformation consultancy focusing on growing client capabilities around the world with 50 offices and 3,500 consultants.

I am so grateful that he has been a programming committee member since 2016, so he's been helping shape the programming that you've been seeing for years. Like all programming committee members, he brings his own problems to the agenda, things he wants to learn, experts he wants to see.

And he brought up something earlier this year that definitely caught my attention. He pointed out that we have a deliberate but explicit bias against outsourcers, favoring instead organizations that have insourced their engineering talent. But we know that this is not necessarily a prerequisite to get great engineering and business outcomes. After all, we've had many stories which feature outsourcers. And he had a fantastic call to action and a direction of programming that we seek to further explore, which is: what do outsourcers and their clients need to do in order to get the outcomes that we all want?

Here's Ben.

Ben Grinnell

Welcome, everybody. Thanks for coming.

I just want to talk about my journey here. My journey, just a brief introduction, started when I flew over to San Francisco for the inaugural DevOps Enterprise Summit in 2014, and I quickly realized what Gene was trying to do for this community was something really special. And having spent 15 years at that point working with CIOs, being a CIO, and working with other IT leaders to improve the perception of their functions in the wider business, I knew how much it was needed.

I remember telling Gene back then that we have to do something like this in London, and I've helped with the programming since the inaugural London event in 2016. Since then, I've been to every event, so this is my 15th DevOps Enterprise Summit. I'm learning more every time and having more stories to share with the skeptics — those people trying to convince the skeptics, or those who just need a confidence boost to stick their neck out and try something new in their organization.

So I love what this community has been doing and what it's achieved through sharing and learning, and how many people we've helped. And I hope everything the IT Revolution team has done with the video library, with Gather Town, and with the focus on building this exothermic community will help all of us do that more easily and effectively going forward.

So today, I want to start a conversation about the sourcing of the IT workforce. It's something I'm asked about a lot, and I don't have the answer. Most IT leaders pursuing a DevOps transformation are trying to change the sourcing mix of their IT workforce in some way, but many don't know what their strategy should be. Through this community, we want to improve the lives of people working in IT.

The idea for this talk came about as I was looking at the programming, and I felt that the millions of people working in IT for global system integrators in outsourced IT environments — and those working with them — are underrepresented, and we don't have enough stories to support them.

So I originally started focusing on sourcing when I started working for the UK government and I became the IT director for the Border Agency in the Home Office. That was 15 years ago in 2007, and I spent three years in that position. And I quickly found that we'd outsourced all of our operations to Fujitsu. Our default development contract was with Atos Origin, and then every major program was delivered by a different one of the big consultancies. We had virtually no in-house capability.

There was nothing in this model that incentivized the suppliers to make each other look good. In fact, quite the opposite — they were always competing. So sharing, enabling, trust, collaboration were in short supply in this ecosystem. All the things we talk about in this community were almost impossible to implement.

Now, the last 15 years have seen a huge amount of progress, particularly in government. GDS was born in 2011 — Government Digital Service, that is — and the drive to break up the monolithic contracts for IT services began. And it's still going on. But today, many of the bigger departments have a much wider range of IT suppliers. Most of them have more in-house capability than they had back then, and some of them have thriving academy programs where they're growing their own talent.

And the same can be said for the private sector over that period. It's undergone a similar transformation.

Now, every enterprise I speak to is trying to grow their internal IT capability. Is that the same for everyone? If you're working for a large enterprise, let us know in Slack if that's the case in your firm.

I'll just pause for a minute so we can have a look.

So I guess that shouldn't be a surprise. The total IT capability they have and need is ever increasing. As Marc Andreessen said, software is eating the world, and an increasing number of firms are realizing that like it or not, they're in the IT business. Business agility is fundamental to survival. First-mover advantage has been surpassed by fastest-mover advantage. Businesses need to be built to change rather than built to last. Changing anything in a large business requires technology change. So business survival is dependent on the ability to deliver technology change fast and reliably. And that's why we're all here, right?

So the challenge that many of my clients present to me is this one: do I have to insource to accelerate my DevOps goals?

There's a lot of evidence that you can hear when you look through the past conferences that suggests the answer might be yes. The project-to-product transformation paper — that is about 100 pages, it came out of the DevOps forum in 2019 — studied 14 enterprise journeys, and some of the findings are shown here. Most of the companies they studied went from 70% outsourced to 30% outsourced over the course of a number of years of that journey.

So a lot of the stories at these conferences are about organizations that have had success by building in-house capability. This year we've got two great talks from TCS: a fantastic story about their internal CEO-driven transformation to Agile, and another about their DevSecOps framework for evaluating their engagements with their clients.

But these talks are in the minority, and I'd like to hear more, given the IT outsourcing industry is worth £66 billion and it's still growing. And that's millions of people working in IT in that environment. We need stories for them.

And even if there's a lot of evidence to support a yes answer, yes isn't a practical answer when I'm talking to a CIO of an organization whose application development and application maintenance contracts are coming to an end. They can't grow internal capability overnight. It's really hard to do, and it's a very hot market at the moment. And the clients asking me this need to procure some sort of support while they try and grow that in-house capability.

And the global system integrators that have built their business around those application development and application maintenance contracts, they have some big challenges. There's a huge DevOps transformation of their own workforce. Contracts that are won with a huge focus on cost reduction and transfer of development risk or operations risk to the supplier — a lot of them are trying to throw risk over the wall. It's very rare that you find that when they launch those contracts, there's alignment between what procurement wants, what IT wants, and what the business customer wants. So they have to deal with that too.

And then there's the alignment of incentives. Ultimately, most senior management at global system integrators or consultancies are rewarded on growing the revenue and the margin on their accounts and increasing the security of revenue. That "get sticky" phrase — that's what drives shareholder value — and those objectives are generally not aligned with what the clients want from them today. Clients tend to want them to help them grow client capability and reduce the dependency. They want to help them use automation to reduce the effort and the time required to deliver the services, and therefore the cost. And they want them to collaborate with other suppliers in a multi-supplier environment so that they help everyone deliver their A game.

So those are some big challenges, but insourcing isn't without its challenges either.

Most enterprises with aspirations to grow their internal IT capability are falling short of their goals. I've got my ideas about why, but I'd like to have a little poll in Slack to see if you agree with me. I'll go through these first, and we can vote on them.

So a lot of the time, there's an aspiration stated in the goals to grow our internal IT capability, but it's just an aspiration without a plan or a concerted effort. The reason it's difficult to get a plan or concerted effort is there's often a lack of leadership alignment about what it means and what the priorities should be. Should we prioritize testing? Should we prioritize engineering? And what should we do to differentiate this from the skills we have today?

There's a lack of constructive collaboration and shared ownership with the HR function. I quite often find CIOs and IT leaders working around the rules put in place by the HR function rather than trying to get them on board and working with them.

And then there is a lot more to growing a sustainable internal capability than people realize. So quite often the effort to do so is completely under-scoped.

And lastly, firms are struggling to put a compelling proposition to the market. It's a very hot market at the moment. There's a war for talent, and sometimes they can't get to the level where they can take money off the table from a payroll perspective. Sometimes because they're trying to modernize, they haven't got the modern tools that people want to work with in place, so people don't want to join and feel they're going backwards. So just getting that compelling proposition.

Now, I've spoken to Gartner and Forrester and lots of analysts, and they all agree that the strategy for application development and application maintenance outsourcing must change. That "your mess for less" era is dead. And it is changing, but noticeably faster on the application development side than the application maintenance. And I think a lot of firms feel there's a risk with application maintenance because it deals with their live services, and they like to have one throat to choke when something goes wrong. So that's why it's slower progress on the application maintenance side, and I'd really love to hear more talks on that.

So let's look at the ways firms are procuring help as those contracts come to an end.

Many organizations are procuring help into capability centers of excellence, aiming to increase their capacity and improve the practices of those communities, hoping in doing so those communities will thrive, break down silos by sharing, and present better opportunities for their own people — and those they're trying to recruit — to develop and learn.

So firms are moving from a pure capacity-via-individual-contractors model to managed services with a service wrapper that includes community and capability advancement. They are usually pure time-and-materials contracts.

But there is a lot the buyers need to consider to set yourself up for success, so their capabilities grow over time.

Firstly, commercially, managed service providers are incentivized to grow revenue and secure long-term revenue, grow margin, secure long-term revenue, drive shareholder value. Secondly, the buyers need to quickly mature some kind of scheduling function so the roles that best suit the development needs of the permanent staff are prioritized for them. Often, their internal business customer will argue for a person from the managed service provider who has more experience, who's done this ten times before.

Thirdly, you definitely need to avoid any sense of competition for roles. It needs to feel like one team across those communities. And having multiple suppliers for the same capability makes that more difficult — I've seen that pattern several times where procurement want to have competition for each individual role. But then it's very difficult to have one team, and it's also very difficult to buy a coordinated approach to that service wrapper where everyone's bringing their own tools and there's no one way of doing things. So I think that's a bit of an anti-pattern.

I think buyers also need to appreciate that the managed service provider also needs to be developing a sustainable workforce. So they cannot just ask for the experts. I hear people say, "I don't want your people learning on the job." That phrase has to be put to bed. You want everyone learning on the job. You're not going to have a learning community if you ban learning on the job for half the people in it. So everyone needs to be learning, and you need to make sure that you're aligning the opportunities with the career growth that people need.

And lastly, I think there's a need to balance the power in this model of the center of excellence and the cross-functional product teams they supply. We know that long-lived product teams are an enabler for DevOps, and if the center of excellence holds too much power, the product team cannot put together and keep the teams they need. If the product teams have too much power, the center of excellence cannot plan their strategic growth and just reacts to demand, and then you're building capability on the scraps of your major projects. In that case, the communities often fall into neglect.

I think the main factors to look out for as you're trying to strike that balance are: how are each funded? Is the money going to the products and the platforms, or is it going to the communities? Power follows money. And the second thing is where people feel their career home is. That's a really important thing to look at.

The most evolved example I've seen of that sort of service wrapper is one where IT and HR jointly procured a managed service which included running of their academy. So the managed service provider came in and worked with both of them to set up and run an academy so they could develop their own talent and build it over time. And that removes one of the biggest problems I see with the drive to — a lot of people put in their contracts, "We want you to build our capability." And the get-out-of-jail-free card is, "You didn't provide us the people." So putting some of the ownership for getting the academy and driving the talent through the pipeline on the supplier side is definitely a way of avoiding that problem.

There are some examples on this slide from Government Digital Service. That's not because I'm talking about government — it's because there's so much transparency on the government framework, so you can easily look at what sort of contracts are being let and who's winning them and what the mix of suppliers is. So I think the same applies to the private sector, but the examples I pulled are just from there because it's more publicly available.

So, many DevOps evangelists will call out functional outsourcing as a constraint rather than an enabler. An alternative that many organizations are testing is to procure a managed service for pods, or ready-made cross-functional teams.

This model also has its own challenges. Do you buy time-and-materials teams, or do you try and procure the outcomes you want from the product or platform? The procurement function will usually favor the latter, as they don't like time and materials. But if you're buying the outcomes, it's more difficult to pivot, and inserting your own permanent people into that supplier team is more difficult. And it's easy for your people to grow product knowledge in that model, but it's less obvious how you build that community that builds the capability expertise that you need on the in-house side.

Again, some more examples there from the government digital framework.

So to summarize, whichever model you choose, I think some of the keys to success are:

Being intentional. Create a sourcing strategy, get leadership alignment across the organization around it, and publish it. If you want people to commit their careers to you and leave their current job, then you need to be very clear about what you're going to build.

Get HR on board and actively supporting the capability build. Don't try and work around them.

Start growing your own at the same time as hiring in the experienced talent. I see lots of people who just think, "I need to hire experienced talent," but without the teams growing under them, there's no career growth for that experienced talent, and they don't stay very long.

Fourthly, ask potential partners what models they're currently using. I think it's a mistake to try and get a partner — however much you like them — to do something that isn't already in their repertoire.

Fifthly, have an open dialogue about your organizational goals and the goals of the potential supplier. I've shown several areas where they are likely to be in conflict. But have the conversations about them — and not just at the organizational level, but down to how the people on each side are incentivized to achieve those goals. They won't be aligned, but the understanding is fundamental to building trust, and trust is a critical enabler of DevOps, and contracts often get in the way of that. So this is a way of stopping that from happening.

And then lastly, as the number of suppliers — or should I say partners — increases, have a look at how you can incent them to help each other shine. Collaboration and trust between supply chain partners is hard because they're generally in competition, but it is essential.

So what I'm looking for help with from this community is: I'd love to have more stories that we can share where these models and others are working. Where has the service provider enabled the growth of the internal capability and reduced the dependency on themselves, and how have they been rewarded for that?

Love to get more stories. We've got several stories through the years on people doing this in application development, less on the application maintenance side, as I said. Really love to hear more examples. And I'm going to lead a track over the next couple of years to help develop these stories so we can help this area of the community more.

And this will start with the Birds of a Feather session on day three — DevOps for outsourcers. So if you're interested, please come along to that. Thank you for your help, and please tell me your stories.