Elizabeth Ayer

Hello, Enterprise Technology Leadership Summit. I wanted to take a minute — my name's Elizabeth Ayer, just to say hello. I'm gonna introduce myself more a little bit later, but first I wanted to find out who we've got in this room. How many of you are buyers of technology services today? All right. And how many of you are suppliers or vendors of technology services? Okay, so a few of each. And the other thing I wanna calibrate on is how many of you have some grounding in Team Topologies already? Okay, good — yes, about half. This is good. And one more question: have any of you actually written a book about Team Topologies? Oh, we do have one. Okay — this will become important later. Fantastic.

Thank you so much for joining me here today. This is a short talk with some very big ideas, so I'm gonna launch straight in. The problem we're solving here together today, the problem statement: we need to work together in groups larger than six to nine people, i.e. the standard ideal size of a team. And sometimes we need to use mechanisms other than hiring to bring people into these groups — that is contracting. So both of these are kind of challenging in their own right, but how do we do them both at the same time? How can they mutually support each other? That's what I wanna talk about today.

These are an apparent tension for modern organizational design and evolution, because something like Team Topologies — which is the foundation for org design I'm gonna be using today — is very much about value orientation, adaptation, and all of those things. But contracting, at least the way we normally think about it, kind of adds rigidity and cost orientation, and it feels like it's got actually a really strong tension there. So how are we actually gonna marry those two together? Can they even fit together?

I'm gonna get straight to the punchline just in case any of you have to go: yes, we can do this. And one of the things I wanna do today is embed a more nuanced and flexible model of contract in your mind, and then use that as a foundation for talking about how contracting models can support modern organizational design like Team Topologies.

So first we have our obligatory slide on reasons we contract. Just in case anyone is in doubt that there are good reasons to contract — we cannot always hire to meet our organizational needs. It allows us really strong flexibility. It shortens the time to bring people in. Yes, this is idealized — that we're hoping to get these things out; we do not always get these things out — but this is why we do it. At its best, contracting can give us these benefits.

However, there are also some pain points related to contracting. Here's where we can go into a little bit more introduction. I work in government, where these procurement pain points are really strong and present. My most recent project that I did with a team called 18F that I work with was about the pain points in state government procurement. And this list and many, many, many more came up. It surfaced a whole bunch of struggles and needs for people doing contracting at all, let alone in the multi-team case.

Now, if you look at a list like this, though, you'll probably notice that a lot of these challenges do not have a root cause in procurement itself. In many cases, they represent some other kind of organizational weakness, or some other problem in governance and communication, things like that — but it all becomes really crunchy in procurement. And so contracting actually magnifies those organizational weaknesses and gets blamed on the contracting parts. It's not always about the contracting, but because it brings those things into sharp focus, it crystallizes them. Then problems of governance, communication, change management tend to appear and look like there are problems with contracting. And it makes it harder once you have something in contract language for people to paper over and fudge things a little bit like they might without contracting — you can kind of just not worry too much about the details in contracts; it puts it right there on paper.

So we do need to make sure that we're working on our organizational structures in order to support contracting at the same time as we're working on contracting to support our organizational structures. That's the main zone of challenge we're gonna talk about today. Obviously there are many other organizational dysfunctions that can lead to challenges in contracting; I'm not gonna go into all of them. This is plenty for us to talk about today already, so we'll draw the line there.

So observations from 18F. Now is where I'm gonna introduce myself a little bit more. I worked with a team that you may have heard of in government named 18F. We were in the news a lot a few years ago, a little bit less so now. You might remember, 18F is an organization that got stood up in the aftermath of HealthCare.gov. And it's an organization which is consultancy by government for government. So I'm a federal employee, I'm not a contractor for federal government — I'm a federal employee. 18F has a really interesting position because of that: they are both government, but they're consultants to government. And so they actually get to see a number of different positions and angles on this problem of trying to do technology transformation and the contracting afterwards.

We are this many people. This is not a lot of people. We are not going to be carrying out single-handedly technology modernization projects by and large, but we can get agencies started on framing their needs and putting that out to procurement. So that's often the role that 18F plays.

I worked with them for five and a half years. I recently moved to an adjacent organization, but my last project is what this is all grounded in. The reason I'm telling you all of this is mostly to locate myself: most of what I'm talking about is going to be from the perspective of the buyer. So if you are actually on the contractor side, I have maybe a little less to say about the things you can do — I have less personal experience of that — so that's something that maybe we can talk about afterwards about how those perspectives can come together.

Now, when 18F started 10 years ago, the contracts that we encountered already going in government tended to either be way too big or way too small — but too small was less frequently the case because those are super hard to manage when you have teeny tiny contracts. Just managing it was a real pain. You can get into some zones in government of dubious legality with that too — about personal services and are you replacing employed professionals? So that was maybe less the problem that we were trying to address. But the "too big" problem was everywhere. It was everywhere 10 years ago when 18F started, with these massive project failures. And it's still happening today. This slide, however, is about six years old, so I feel like I can put this up with nobody in this room going through one of these painful experiences. But I assure you there are contracting failures going on right now in the hundreds of millions of dollars. And by failure I mean where the state — or whoever is doing the contracting — doesn't get anything delivered out of the thing. Maybe they went through a requirements exercise for a couple of years and then doesn't get delivered software, and these things are still happening. We are not done with this problem.

As one of my procurement colleagues likes to say: we're still contracting for software like we're building a bridge. I refer to my procurement colleague — I myself have a product background. I've been a product manager — I was a product manager in private sector for a DevOps tooling company actually for about 10 years before joining 18F, and then within 18F having a product role.

So: contracting for software like we're building a bridge. And 18F thought, ha-ha, we know what we can do about this. In addition to the consulting work that we're doing, we will also write up the great compendium of Agile philosophy for government audience and put out a thing called the De-Risking Guide. Which is up today — there's actually an update coming out in a few weeks' time, which again brings it more up to date with modern practices.

What this really did though is it brought that Agile philosophy to language that procurement people in government could actually start to engage with, or technology teams in government could engage with a little better. But it focused on a single empowered Scrum team as the fundamental unit of delivery — which I think is not wrong, however, in the intervening years we've learned a few things. One of which is that the one-team case is incredibly rare. I don't know if you remember back 10 years, but then we thought we could kind of incubate a small change initiative, and then once everyone saw it succeed, we'd say "ta-da," and the change would just roll out to lots of other places. Well, that didn't really happen. The one-team case was exceedingly rare for being able to actually deliver software in government. And some of that is because of the auxiliary services, all the different functions you would need to work with. So in government, just like in enterprise software, it's not very likely that you're going to be doing a lot in a one-team case.

Number two is that technology transformation takes years to stabilize. Again, I think that folks thought back in the old days that as long as we sort of did things right and showed people what good looked like, we wouldn't need to take the same timeframes as it would take a normal technology program to be rolled out. However, as we found out, these organizations change slowly. So even when you're doing all the right things, it still takes a really long time for the change to bed in.

And put that together with number three, which is that small changes tend to get squeezed out. People talk about the organizational immune system and things like that. I personally don't think it's quite as intentional as that — I think it's just change takes a lot of energy and people get tired. And so the change actually fizzles in so many cases.

So you put those things together and it suggests some really important things about our levers for technology change in enterprise environments and government. And the main one is that we need to act at the systemic level — which I think is very much a part of what this conference is about in the first place. If we take that to just contracting, though, it also means that any contracting in service of major change has to support flexible multi-team organization. It has to do this. You cannot have a transformation program that does not do this. It does not mean that it's sufficient, but I think we know from these three unarguable things that that is really necessary for these programs.

So: enter strategic sourcing. This is where we get some flexibility to our contracting approaches. I do realize that in procurement circles, strategic sourcing is sort of like Agile — it has been overloaded in certain very specific ways to mean category management or something in that kind of zone. I'm gonna peel that back, sort of like you might with Agile, to a little bit more of the original intent behind these words and behind the concept. And this is about contracting methods that can focus on value over just cost.

The way many of us think about contracting is what we can call a transactional contracting model. And lots and lots of people still think of it this way: that we need structured, explicit contracts that get us what we need to get. We decide exactly what we want and then we try to pay for it as little as possible — we wanna spend as little as possible to make that thing happen. And there was a big movement towards this philosophy, especially in the eighties or nineties, where it really became the buyer's job to leverage their power over suppliers. It set up immediately an adversarial relationship with them. And sometimes it means there's an obvious play that those suppliers come back with — which is to go in with a low price and then make up all the money with change orders. So there's a natural sequence of events that's gonna happen when you take this adversarial posture. And there are still people who think that they are obliged to screw their suppliers if possible. So I wanna make sure that we do away with some of these old ideas and get a more humane foundation for our contracting.

It turns out that that is a very short-termist approach — who knew. Okay, we all could have guessed that. But the more important thing than just not giving the company what they want over time is it actually can ruin an entire supplier ecosystem to do this. There was a really interesting paper put out by an economist named Oliver Williamson. He's best known for transaction cost economics — we don't need to talk about that, we've got enough big ideas already, but super interesting stuff. And he called that approach of really putting it to the suppliers the "muscular approach." And he said that that was myopic and inefficient, and then demonstrated that in this really crucial paper, and actually proposed the alternative method — which is, for complex problems, you want to go for adaptive cooperation instead. You can't just step back and say, "Oh, sure Mr. Supplier, whatever you would give it to me" — but you shouldn't go in with that muscular approach and really take control of the situation. Instead, build those trust relationships. And that way you can jointly solve complex problems.

Which is when we get into relational services contracting. So this is another way of thinking about doing your contracts. And the attributes of this kind of contracting, as opposed to transactional, which was about buying your things — this is about specifying the goals that you're working for, and building mutual value. So instead of slicing up the pie, you're looking to build a bigger pie with your suppliers. This is really good for early-stage problems, for medium-trust situations. And the key phrase — whereas before it was "never leave money on the table, that value is yours" kind of approach — this is always leave money on the table. That's the best sign of cooperative intent that you can possibly give: is to actually leave some room there in the negotiated solution. So examples of this that we've seen — you can actually do more collaborative work together with the foundation that actually gives you the trust as early as the contract itself.

Now, these aren't in binary opposition to each other — they're along a spectrum. On one end you might have statements like "our joint objective is..."; on the other side, you might still have "the system shall...". And I'm not trying to say transactional contracting never works — but for the majority of our hard problems, which are those transformation ones, it's just not a very good fit.

A quick thing: it's also not like a relational contract or a transactional contract — you have many different contract types. Again, not gonna go into detail on this, but I recommend taking a look at a book called Strategic Sourcing in the New Economy; it talks about seven sourcing business models, and I'll put up a reference for it later. There are different places along this spectrum that you can tune your contract depending on those attributes that you have in your situation, about what the level of unknowns is.

Some of these — one side is better for strategic needs, for when you have significant unknowns, for innovation, and for what I'm calling "hot" environments, when you have a lot of energy coming from the outside, from stakeholders, potentially very high risk. Whereas the other side, the transactional one, is actually really good for tactical needs, at times when you've got a super well-understood problem and you can articulate it. You can just have that sort of lower-energy, commoditized relationship with people. And we do it all the time in non-services contracting — obviously we can do it here too. It's just a little less common.

And 18F uses this. In practice, we very habitually write statements of objectives rather than statements of work. Instead of doing long requirement specs, we'll do a contract that looks like roughly this format. It tends to be very short — you don't need to go beyond 10 pages in many cases — which means you have a lot less to argue about when you're trying to actually finalize it. So you can get more resources in 18F's. There's some information on GitHub. There's some information on its blog about this.

And so in summary: you want to be using relational contracting, flexible partnership models, when the problem or solution isn't very well understood yet. I think we should probably all be down with this. We know that when uncertainty is high, we don't wanna over-constrain our solution space. We know this, right? I think the only novel thing here is that we can get that out of our contracting too, and we can actually put a foundation in place which continues to give us that even when we don't have hired employees.

The other thing I wanna mention — like a corollary to that — is that many times people's needs are more strategic than they think. There's a bias in enterprise technology, and society more widely, towards demanding and displaying certainty, which pushes things to make us think they are more transactional and more defined and more clear than they actually are. So while we would like to have everything be known, we need to be realistic about what is actually known in our situation, and very clear-eyed when it comes to understanding the level of collaboration that these things are actually taking.

All right, contracting — hopefully you all now believe that there is another way that can give us these things we need. So we can talk about how we actually go from one team to multiple teams, and how we actually extend this in this environment.

And this is where I want to apologize to anyone who may have written a Team Topologies book for distilling it to two bullet points on a single slide. But these are the points I think we need for the purpose of this conversation. First of all, that the fundamental building block of organizational design is a team. And the second part is that it's not enough to have teams be customer-focused — your structure needs to be customer-oriented too. Hopefully that's okay; we can talk about it afterwards if there's a problem.

Looking then at organizational diagrams — Team Topologies diagrams. I'm not gonna go into any kind of detail; there's not time for this. Read the book, it's great. Instead I just wanna talk about a couple of attributes of these diagrams which you may have seen. These top yellow sort of streams — these are stream-aligned teams delivering value out to users along the top. And then we have some platform teams along the bottom here. These stream-aligned teams — the value in these needs to be pulled by the customer. This is the really important point here. We've taken from Lean philosophy of software — it's really important that the customer is actually pulling that value rather than being pushed at them. And the reason that this is important is that it aligns the flow of change through this organization. So the customer, or the consumer in this case, can be pulling from the stream-aligned team. And then those stream-aligned teams are doing exactly the same thing to their platform teams — they're pulling the value.

And what this does is it actually gives the conditions for flow, because all of those arrows are lined up to let things flow through the organization. And you do not get good flow when you actually have pulls in different directions — when things are janky that way.

The reason this is extra important in the contracting situation is that it's really common for the buyer to have contractors be delivering value to them, and to set it up as an either/or between them or the customer. And this is a huge problem because that sets up a flow misalignment. So it's extra important that buyers actually align the incentives around those user needs if they want change to flow through the system. Again, I can't emphasize enough — and this is one of the mistakes I think we mostly see out there — is just having that pull in all kinds of different directions. Just make sure it isn't an either/or choice.

So how do you get to one of these value-oriented structures? Well, in the non-procurement case, the answer is evolution facilitated by a Team-Topologies-savvy enabling team. It's all very simple. Okay, it's not simple — obvious, it's not simple — but the broad philosophy here is that we can evolve boundaries to allow decoupling. And the decoupling is good for all the reasons we know, because that allows flow, allows change to proceed independently, allows empowerment, allows all kinds of parallelization going on. And so this will often happen by periods of collaboration where you start to figure things out, and then you move towards that as-a-service relationship. And those are the two major interaction types. There's another one of facilitation, but I think much of what we see in organizations is either collaboration or as-a-service — and you're going from collaboration to figuring out how to work together as-a-service. This is all the last part of the Team Topologies book; I know it's not normally worth reading business books to the end, but read this — it's at the end, it's good stuff.

And so when it comes to this original relational/transactional spectrum — these aren't necessarily, it's not like all of these go together — like collaboration has to be only in this side and as-a-service is only in that side — but these are again the places where things fit really naturally. When things are in that relational space, you will need that collaboration. So you need a structure that allows for that collaboration. And then as things maybe cool down a little bit, as things become better understood, you're looking to move them towards the as-a-service kind of mode of interaction.

So how do you do this with a contractor team? Wow, we put the two halves of the talk together. Hooray. The point is: give yourself a good contracting foundation that lets you do this — that lets you work in a relational way, that lets you have the flexibility you need to be able to solve your problem for real — and then use that to evolve towards boundaries that allow decoupling. Now this means that you cannot have crisp contract boundaries between teams. So for example, contract out separate parts of a problem in the early stages of innovation or of transformation — you can't do that yet. So you at least need to allow yourself some fuzziness. If you do need to put this out to different people or divide it up among teams, you need to allow yourself some flexibility at those boundaries to evolve those structures.

I'm gonna give a really quick example. This is like a micro example, but the watchphrase or catchphrase here is "discover to establish": you do that collaboration so that you can figure out what the as-a-service or what those splits might be between the teams. In this case we have Agency A interacting with Vendor V. This was for a congressionally mandated piece of software, and so they were starting from scratch — blank sheet of paper. They had a lot of agency in what they were doing. It was net new. However, it was going to be rolled out to states who needed to deploy the software within existing business processes in a really very challenging environment. And so all the while the software is getting built, user-tested, making its way through compliance, doing all those things software does — but the part about working with the states, which was a complex combination of policy and technology rollout, just kept kind of falling behind and kept not getting taken care of. They thought initially — both sides thought — that this was a one-person problem to start with, and it was only through the act of trying to do the work that they realized this was significantly larger; it needed wider range of skills, it needed additional time. So among all the software needs, which were concrete and well understood, it was just kind of falling by the wayside.

They didn't wanna do any kind of separation of the state-rollout piece from the original software, for very reasonable reasons. They looked at the additional coordination cost that was going to mean for them. They felt like they would lose some economies of scale. This wasn't something where they're like, "Yes, this is obvious." However, where the boundary could be was reasonably obvious to them. And so what they did is they used that kind of natural fracture plane through the different activities to set up two different value streams, to actually separate them out and untease them, and ring-fence some folks to work on that piece that was getting under-attended in the short term.

So again, this is a really micro example of just one value stream splitting into two value streams. But I think it's important because these things are difficult. You've got people who like working together often in there, and there are often things pulling against you trying to do what are structurally somehow obvious from the outside — can feel not obvious at all from the inside, especially when you're going from a collaborative to an as-a-service model. Because it's not surprising when people are collaborating and like collaborating and it's all working, they wanna keep doing it. And so there isn't always a natural tendency then to separate and formalize. And so this sometimes can use a little bit of help and facilitation from the outside to get to the place where the organization needs that to be.

These were contractors all in this vendor team that got split. And so in some ways it was an easy thing to do because the agency can just do it. But it also needed the vendor team to be sufficiently bought in that they could actually act in full concert in doing this. It does get a lot more challenging when you have a number of different vendors in play, or when you have the sort of mixed teams, blended teams. And there are a lot of situations where you've got to be using that constant sensing and responding to the situation you find yourself in, in order to actually make those structural changes that'll let you evolve to lower-energy states.

So in short: prefer relational contracting, collaboration interactions, for the less mature services and needs, and work towards maturing them. You sometimes need to zoom out to be able to see these things and facilitate people through this — but then get back in the work.

One of the things I loved about Gene's opening intro was the phrase — I love the phrase — "liberate creative potential." And to me, this fits perfectly with that phrase, "liberating creative potential," because right now we are beating the creative potential out of these contracting systems before it ever has a chance to flourish. So instead we can give it a chance, we can give it a foundation, and give the collaborations that need to happen to solve complex business problems a chance.

So in summary: yes, single empowered Scrum team was a start, was a fine start — let's move on. We can use a range of contracting models from strategic sourcing; if you've never heard of this before, I really encourage you to take a look at it, because it kind of will blow your mind with some of the ways and creativity that people can bring to the act of contracting. It's not brand new, by the way — people have been doing contracts like this for a long time. I think the major innovation of it was to say it's okay, and this can give good outcomes, and to show plenty of cases where it has given good outcomes without feeling like they have to take a muscular approach.

Relational contracting often fits the software world better. Many of us are working in cases where we have a ton of unknowns, especially in early-stage transformation projects. And you need to expect change in the less mature components. So as you're figuring things out, those understandings of the problem will change, the activities will change, the needs will change in so many different ways. The org design can change. But a contract — if you're not careful — it can prematurely freeze your structure. So just make sure that you're giving yourself the latitude in the contracts to be able to adjust as necessary, and then mature your boundaries as the understanding increases, and potentially recontract out as you actually really understand what those service interactions need to be.

Quick flashing up of the resources. These are the books that I referenced very, very heavily in making this talk in the first place. I've got copies of them with me if you wanna take a look afterwards before you buy. The article on outsourcing that I mentioned — the 2008 article that got Williamson the Nobel Prize in 2009 — again, it's worth a read. It's not long, but it's slightly heavy going. But it really gives the foundation of that adaptive cooperation model for contracting. Secretly there's Wardley Mapping going on here, and there's some really good information about maturing things — moving from genesis to commodity, software. Take a look — there's some really good things also about contracting, especially in this and managing things in the same maturity state together in the same contract, which is very, very resonant with the themes of this talk.

Another thing that I highly recommend if you are tempted by trying to do this at scale: I think Susanne Kaiser put together a wonderful flow of DDD and Team Topologies and Wardley Mapping, and how those things can work together to find your boundaries, understand its maturity, and get your Team Topologies structures in place.

And finally then we have, as I mentioned, the new updated De-Risking Guide coming out hopefully soon. I would check back in in September. But I think it's also a very useful artifact when we're trying to communicate this to other people who might not be bought in yet — because obviously it's not just you who are gonna be making these decisions; there are a lot of people you need to work with too. And so some communication artifacts, whether it's this or other things, we find are really critical. So thank you in advance to those of you who write these and share them, because I think that is the essential maturing of our industry.

And my call is: let's keep the conversation going. We have networking after this. I don't have time for questions now, but I very much think this is a nascent set of ideas that are really exciting for being able to transform the way that we actually do software in a way that takes account of some of those more enterprise needs. So please keep the conversation going. Talk to me, talk to each other. And thank you very much, both for being here and thank you to Gene for inviting me and having me here. And have a great rest of the conference.