TL;DR

I started a new job yesterday that boils down to applying data driven (re)design for operations (DevOps) to what’s now one of the largest Global IT Services companies. After leaving the startup world for ‘a bigger train set’ the scale just got bigger still. The size of the task ahead seems initially daunting, but much of what needs to be done has already been figured out, and there’s a great team around me.

If you’re not interested in the personal journey and mergers and acquisitions stuff here then skip ahead to ‘So what does a Deliver CTO actually do?’ below.

Background

It seems that I only write about my work when I change jobs. This time it’s a bit different, as the company I worked for changed around me, and I ended up with (sort of) the job I was hired to do.

Yesterday CSC merged with HPE Enterprise Services (ES) to create DXC.technology. The Global Infrastructure Services (GIS) organisation that I worked for ceased to exist, and I moved to the new Global Delivery Organisation.

The story so far

I started at CSC at the beginning of December 2015 as the CTO for GIS, which with revenues in the region of $4Bn was about half the company following the spin out of the US Public Sector business to CSRA. In May 2016 I was tasked with setting up the Operations Engineering (OE) group, which I handed over to Greg Dietrich in August; and then I was asked to be general manager for the x86 and Distributed Compute business. Quite a ride over the course of 16 months.

Not quite as expected

When CSC first approached me in July 2015 it was for the job of GIS CTO, but as the hiring process was nearing the end I had an in person meeting with Steve Hilton who told me that there were plans to restructure the company along the lines of Build, Sell and Deliver. He expected to be running the Deliver piece, and he wanted me to be Deliver CTO. That was a moment where my mouth ended up saying ‘yes’ whilst the back of my head was saying ‘you need to go away and think about this, there’s still time to escape, you’ve not signed anything yet’. After some consideration, I took the job anyway; Deliver sounded a bit boring and back officey, but there was clearly lots of interesting work to be done.

I next got to see Steve a few months later when he got his leadership team together at the (then) CSC HQ in Falls Church. It was clear that not only had the organisational change not happened, but there was no sign of it starting. ‘I spoke to Mike about that last week, and he’s gone off the idea’ seemed pretty inadequate. A CEO nearing the end of a (successful) major turnaround surely couldn’t be so capricious.

It was an almost 4 month wait for a proper explanation. The public announcement of our impending merger with HPE ES made it quite clear why we were holding back on restructuring – why change CSC when it would just make integration with a similarly organised ES more difficult.

Got there in the end

So yesterday I became the Deliver CTO – the job I’d signed up for, just with a much bigger Deliver organisation.

Both sides happy

I’ve seen a lot of mergers and acquisitions during my time in the IT industry, and in almost every case there’s one side thinking they’re winning, and consequentially another side that comes away as the losers. As we’ve brought DXC Technology together it’s not felt like that. The CSC people have been positive about the move as it’s brought us from near the back of the IT services field to near the front. At the same time the (mostly ex EDS) ES people have been positive about moving away from a single vendor and becoming an independent services pure play (again).

That’s not to say that every single person is happy. Like most mergers there are ‘synergy’ savings that have been promised to Wall St, so that means a bunch of people who don’t have a seat when the music stops. Bringing together two similar organisations inevitably means that you end up with (more than) two of everything when you actually need one; and that applies particularly at senior management.

So what does a Deliver CTO actually do?

Firstly it’s worth unpacking the three letters of CTO:

• Chief – a leader, who points the way for the rest of the organisation.
• Technology – understanding the constantly changing environment, continuously learning and teaching others.
• Officer – making decisions within a delegation framework, and helping others to make decisions.

The Global Delivery Organisation encompasses everybody involved in making stuff actually happen for customers, so it covers a lot of ground; but if I grossly oversimplify it turns into two different takes on DevOps:

Internal: All in on Operational Data Mining

Operational Data Mining (ODM) is the way that we’ve been improving operations at CSC, and is a discipline that will be central to how we make DXC Technology work. It goes like this:

• Collect data exhaust from service management and ancillary systems
• Analyse to identify operational constraints
• Model the system being worked on
• Hypothesise a way to improve the system
• Experiment to see if that works
• Rinse and repeat

In terms of the ‘three DevOps ways’ of flow, feedback and continuous learning through experimentation this is clearly the third way, but it applies to the first and second too. In every case we’re trying to improve the flow of work (first way), and we’re generally trying to build systems that provide faster feedback (second way). This is quite simply the implementation of what’s in the DevOps Handbook, which is in turn everything that the manufacturing industry learned about process improvement post WW2 (Deming etc.). Science not magic, and it works.

The great thing about doing this in a company the size of DXC Technology is that the experiments can be parallelised across multiple regions and accounts. Furthermore we can identify repeat patterns and apply them with less setup cost and time.

External: Design for Operations

Build, Sell, Deliver can be conceived as a triangle, with bidirectional relationships on each vertex:

• Sell what we have Built
• Build what we can Sell
• Sell what we can Deliver
• Deliver what we have Sold
• Deliver what we have Built
• Build what we can Deliver

Here I’ll concentrate on the final point – Build what we can Deliver.

This is a point about design. We should think about design for operations when an offering is put together. It’s not enough to just build what the customer says they want (Build what we can Sell), we need to consider the delivery experience (and associated costs) for turn up on day 1 and ongoing operations from day 2 to infinity.

What we call ‘DevOps’ is just a bunch of artefacts that come from organisations that have designed for operations (which generally tend to be software as a service or software based services). This isn’t even a software thing – just about every industry evolves from design for purpose through design for manufacture and to design for operations (sometimes called design for maintenance).

Design for operations isn’t an enormously complex thing to do, it’s just about ensuring that operational considerations get included alongside other functional and non functional requirements. Once again data can be brought to bear, because we can use data about the cost of operations to drive investment decisions around the design of offerings.

An example: Modern Platform

Modern Platform is a virtual infrastructure offering that’s been designed for turnkey operation on day 1 – plug it into ‘power and ping’ and it’s ready to go after minimal configuration. This is largely achieved by the approach of using a partner engineered system, but that’s irrelevant to design for operations – it’s just pushing work into a place within the value chain that has best scope and scale.

Modern Platform provides an offering in its own right (for customers that just want [more or newer] virtual infrastructure), but also a foundation for higher order offerings like workplace and private cloud. Here the design principles can be pushed higher up the stack. If I can get a turnkey virtual infrastructure then why not a turnkey virtual desktop infrastructure? (and so on).

The challenges ahead

Top of my list is restoring/engendering psychological safety. Google’s research into differentiators for high performing teams identified it as the primary determining factor, but both organisations have been battered by years of cuts and the machinations of the merger. Now that we’re together as one we need to make as many people as possible, feel as safe as possible, as quickly as possible; we need to create belief for individuals in their place within DXC Technology.

Beyond that lies the need to reskill for a cloudier future. Ops people who are used to eyes on glass and hands on keyboard and mouse need to get familiar with the disciplines of software engineering as infrastructure becomes code. CSC came some way on that journey with Infrastructure as Code Boot Camps, but scaling that to a much larger delivery organisation will take a different approach, and there’s also a need to go broader and deeper.

To earn our share of the shared responsibility model that comes with cloud will require greater application intimacy, which needs to come both top down (business needs to app) and bottom up (infrastructure services to app). The concepts from site reliability engineering (SRE) that were used in founding the OE team will be essential, and Ian Miell shows just what it takes to achieve application intimacy in ‘Things I Learned Managing Site Reliability for Some of the World’s Busiest Gambling Sites‘.

In good company

I was attracted to CSC by Simon Wardley, Glen Robinson, Sam Johnston and JP Morgenthal joining ahead of me (and that’s before I got to properly know Dan Hushon). Those hires were clearly about growing a team that understands next generation IT. It’s a group of people who understand the need for situational awareness and mapping, who get OODA, who adapt and evolve but also learn and mentor. Since joining CSC I’ve been impressed by almost everybody I’ve met there, by their technical skill, willingness to learn, and resilience. As I’ve come to know my new ex ES colleagues they’ve impressed me too, for there’s a great deal of shared experience and shared culture in both firms. It will no doubt be a tough road ahead, but the journey will be easier with such good company.