Composable Teams

0:00 - Intro

0:00:28 - What is a Composable Team?

0:03:05 - What are the benefits of having a Composable Team?

0:05:57 - Isn't it easier to go with SAP or Salesforce?

0:07:37 - Right architecture with the wrong people.

0:09:03 - Diversity brings better results

0:12:23 - Are Composable Teams much cost effective than a large Monolithic Team

0:16:12 - Cost vs Quality and Priorities

0:17:46 - Measuring Productivity between Composable and Monolithic teams

0:20:45 - Illustration between Monolithic and Composable Teams

Hi, welcome back to the Goodfrontend Show. Today we're gonna be talking about composable teams. What is a composable team? How would you describe it?

Yeah, I would describe a composable team, not too different from composable technology, composable architecture. So if you think about composable technology, you might separate a Search API, you might separate a Content Management System, you might separate a Commerce API, you might separate your platform. And how I'm describing... how I would describe a composable team would be in a very similar nature to how you create separation of concern for your technology. In the same way that you would compose your technology, you would also create teams that specialize in maybe a certain vertical or a certain horizontal, and that would be the team that focuses on that specific area.

So just like where I'm at now, we have different feature teams. So is it like that?

Yeah, that's one way to manage a composable team. So I guess it's no different from what we already know. For those people who are coming from a proper agile background where it's product-led, you know, we might have, let's say a team called "Team Inspiration" and they would focus more on Content Management Systems and they would focus more on the homepage, the content pages, landing pages, and then you might have a discovery team, which is more focused on Search and Merchandising. They would focus more on the listing pages and so on. And you might have a conversion team, which would span all the way from OMS all the way to the checkout and then to the returns flow. So that's one way to manage teams in a composable way, if you like, by creating verticals. There are other ways as well, if you're a smaller organization, by maybe creating horizontals. But I would say that from a composable perspective, at least for headless, at a minimum you should create a composable team for the storefront, which focuses mainly on customer experience. And then, you know, a team that then focuses mainly on downstream systems, maybe focusing more on system design and scalability and so on.

M-hmm. So I'm hearing like there's quite, it's quite flexible, isn't it? But what are the other benefits of having a composable team?

Composable teams... I'm just using it to describe, I suppose, what we've already known in the startup world as product-led and lean teams and so on. But composable teams are small teams effectively. Research has proven time and again that smaller teams are simply more effective than larger teams. It is almost the same as monolithic technology. Monolithic technology, you have this one big box and you do everything there. So you lack the flexibility, but when you break it into smaller modules, then it becomes more flexible. That's the same thing with teams. The idea is that you create smaller teams so that you are more agile. With smaller teams also, you can have multiple different vendors at play, which means that you can potentially have cost savings. You might, let's say for example, you might hire a specialized team focusing on the storefront who specializes in that area.

And because they are quite good at that, they would have reached the levels of economies of scale. For example, GFED would fall into that category whereby we're quite good already with storefront engineering, creating backend for front and layers. And so we will always be more cost-effective than any other generalist providers. We will always be cheaper, and I'd be quite surprised if we weren't. And that also falls down to the fact that smaller teams simply have less overhead. If you think about it, if you have this large system integrator, they have so much overhead just to get things going. Whereas if you have smaller teams focusing on certain areas, there are fewer overheads and also they are specialized in those areas, which also means that management and measurability of those teams are a lot easier to do.

In terms of management, isn't it easier to manage one big single vendor that provides you that team as opposed to having several different small teams?

Yes. I think there is an argument to be made to say monolithic teams are easier to manage because you're just managing one system integrator per se. But that argument can be used with composable technology.

M-hmm. Isn't it easier to just go, let's say with SAP or Salesforce?

M-hmm. You know, rather than signing up for a Search API, Commerce API, Content Management System. So different contracts, of course, that would be easier, but the point is you're just managing it differently. It's easier in the sense that you go to a one-stop shop and you have everything you need there, but it's not best of breed.

Mm-hmm. I see.

You know, so in the same way when you're going to a single system integrator, for example, yeah, they have everything that you might need there, but again, it's not best of breed. There is no guarantee that they will be able to provide you a best of breed team because a large system integrator with thousands of people, they might do a composable project, but it's not necessarily the case that the people who worked on that successful project will be the same people that will work on your project. And it's not uncommon for us to hear about these huge system integrators.

Yeah.

Who are well known, whether they're Mac certified or not, mm-hmm. <affirmative>, you know, to do two projects, and one is super successful and one is an utter failure, you know? Mm-hmm. <affirmative>, and that's because it's different people running the projects at the end of the day. So I wouldn't necessarily say it's easier to manage. I would say it's a different way of managing. And again, the other way I guess that I would want people to look into this is... it's almost like you're choosing the right architecture with the wrong people. Mm-hmm. If you prefer monolithic teams, single provider, you're better off with a monolithic architecture. Mm-hmm. Yeah, because otherwise, you will have a solution that is not composable. You will have a solution that is composed as some people would like to say it.

M-hmm. <affirmative>. So if you go with the composable team, it gives you the flexibility to pick the right team for that particular feature. So you get the best of devs that specialize in that area. As opposed to just going with a big vendor who could randomly just give you a random dev. They could be senior and have experience as well, but you know, there's no guarantee that they could give you the best results. I see that a lot of companies they get into diversity and inclusivity as well. So by going towards a composable team, it kind of gives you that, uh, that diverse background is in it. Because it opens up a lot of opportunities for small companies who really specialize in one area, and then you could get other teams to come in as well.

I think that's true. Diversity and inclusion, of course, is not a tickbox exercise. There is evidence that suggests that diversity does bring better results. Mm-hmm. <affirmative>, diversity does not necessarily mean the typical things like age, gender, religion, or whatever, but it's diversity in thinking that truly is what brings results. And ensuring that the right type of thinking is applied in different systems is so important. For example, if you're thinking about storefronts, you want people working on that to be customer-centric, customer-specific. If you are thinking about event streams or OMS, you want them to be more system design thinking, you know, so different parts of the system, in order for them to be successful, have a different way to think about software. Mm-hmm. <affirmative>, and creating a monolithic team, you cannot guarantee that. The only way you can guarantee good results in different places is to ensure that the friction is there that exists, you know, amongst different types of teams that think differently, diversity as we would call it, for them to work together and come up with a result that really benefits the business and the customers.

How do you think composable teams can be more agile than large monolithic teams?

The simplest illustration that I can think of is to imagine monolithic teams similar to the Titanic. The Titanic is a super powerful ship, if you like, but it cannot maneuver when the iceberg was there. And that's the key issue, isn't it? We live in an age now where it's very volatile. We never realized the pandemic would hit, a war would hit, a cost of living crisis would hit, and a Titanic ship is helpful if you are trying to get things in mass and get somewhere. But it's not helpful when you're trying to make a turn. And we're at that situation now in this economic uncertainty where people need to keep turning for them to survive, and a mon

olithic team is like a Titanic ship, it cannot turn because it's too big. A composable team, a smaller team, an agile team is a lot more like speedboats. A small team, a speedboat is able to see the iceberg and turn easily because there's less overhead and fewer people, and you know, the risk is distributed because you will have multiples of speedboats as opposed to, you know, having just one large Titanic. Sure, it is easier to perhaps manage a huge Titanic ship because there's only one ship, but then when it goes wrong, it completely goes wrong.

So it's kind of like a MicroFrontend App, right? So one area could go down, but the whole rest of the application is still ongoing.

Yeah, absolutely. Yeah. It's the same with microservices or federated GraphQL servers and so on.

Mm-hmm. <affirmative>, but if you have this big monolithic app, one area goes down, then the whole application goes down.

Yeah.

What about cost effectiveness? Is composable... a bunch of composable teams much cost effective than a large monolithic team?

I think so. I think it largely depends on the type of teams, of course, that you can compose, but the key thing here is that organizations have control over their cost. Mm-hmm. <affirmative>, here's the issue sometimes that many brands and retailers face when they're working with a large vendor. So again, I won't name any specific vendors, but some brands and retailers would have license fees with a vendor, and they are in a vendor lock-in situation because this e-commerce platform that they are paying pretty much has all the things that allow them to upgrade. And this vendor would charge them license fees, and this vendor can charge them a high penalty if they want to. If, you know, the brand or retailer refuses to upgrade because they don't see the benefit in it, that's bad. Right. And so composable helps you because you break down your software, and you can have more control over your vendors. That's good. Now, when it comes to teams, to system integrators and so on, however, is that if you carry on with one single system integrator, that is like the same as carrying on with one technology provider, it's like a vendor lock-in. But it's even worse in my opinion because at least technology is predictable, but a system integrator that is built with people is not predictable because people are not predictable. So if you are in this vendor lock-in situation with a system integrator, in my opinion, that's not the greatest result. Yeah, there's serious look at it. If you manage to get a good deal with a system integrator because of economies of scale, you might be able to get a good deal. The downside to that is they effectively dictate the price to you mm-hmm. <affirmative>, right? Because if they, uh, if, if they have to raise their prices, what choice do you have? Right? However, if you did choose to go with a composable team, you can still choose a main system integrator to look after most parts, but you might choose, let's say a very specialist team to work on certain parts, or there might be parts of your technology stack that are not so important to you. So you would choose a very cheap provider, you know, so with a composable team, you can choose a vendor that is a specialist of high quality, of high cost, you know, and you can also choose a generalist provider of low cost. And then you can have a system integrator also who can do all the other bits. Mm-hmm. <affirmative>. So if you have that ability to be able to manage things well, you know, it's the same thing as managing your technology. You could potentially put down your total cost if you go with a composable team. Again, it's something that organizations will have to try out. But at a minimum, I would say that at least working with a smaller team like GFED or other organizations like us, because we're small, we don't have a lot of overhead. So we would always be cheaper than larger system integrators.

And just thinking about low-cost providers, it doesn't necessarily mean that you would end up with a low cost. Because it comes with quality as well, isn't it? So let's say you give it to a low-cost provider, the guarantee of the code quality, you never know. It might come up with loads of bugs, and then you have to extend your contract because of that and, yes, yeah, yeah. And in the end, it costs even more than having a high-quality provider.

I think you're right. What I was meaning more is sometimes you might have a system that you don't necessarily see as a top priority, mm-hmm. <affirmative>. And so you might accept the risk that there will be more bugs for that specific system. Let's think, for example, let's say you want to create a loyalty program, and loyalty is something that you might want to do because you are ticking a box but not necessarily important to your organization. You know, so you might hire a low-cost provider to do certain things on loyalty, to do a tickbox exercise, but you accept some level of risk. At the same time, you might choose, like for your storefront because it's your customer touchpoint, it's where your brand is communicated to your audience. You might choose a smaller specialist team of higher quality, you know, mm-hmm. <affirmative> to work on that as opposed to getting a generalist provider. For storefronts, you might want to have a specialist frontend team working on it.

And in terms of measuring productivity, how do you think composable teams differ from larger teams?

It's no different from software, I would say. If you have a large piece of software, it is very hard to debug. Mm-hmm. <affirmative>, let me, uh, put it this way. It's a common problem for many organizations whereby, let's say they want to make a release, they want to make a change to their checkout, but there is an issue with their listing pages. And so it blocks the whole release. That's like the monolithic thing, and it's so hard to know how to measure exactly what's going on because they're all so interrelated. It's like this big black box, mm-hmm. <affirmative>.

However, if you are creating composable teams, let's say you have a discovery team, an inspiration team, a conversion team, a technical platform team, you know, you can easily see, "Oh, okay, this team is producing this amount of work, this team is producing this amount of work, this team is producing this amount of work," you know, and you can see for different teams, because they're smaller, which ones are performing and which ones are not.

You can objectively say, "Oh, this part of the application is a lot more performant than this one that this team has created. Why is that?" You know, you could start asking more questions because you break down your system and your teams into smaller pieces, if you like, and it's a common way to solve a problem, right? If you want to solve a big problem, the simplest way to solve that is to break down that big problem into smaller problems and deal with it one by one. Mm-hmm. <affirmative>, that's what smaller teams give you. Composable teams allow you to break down the big problem into smaller chunks, and you can easily measure whether each of those composable teams is working or not.

Just to summarize what I understood, composable teams are more agile, they're more cost-effective, but it requires a different way of managing compared to a big monolith team. Did I miss anything out?

No, I think that's a fair summary. Just to touch on that point about a different way of managing it, just because I don't think I was very clear on that. I would say that composable architecture is a bit like implementing a democratic government in a country. And a monolithic architecture is a bit like implementing, say, a communist government if you like, or a heavy-handed leadership government in a country. Monolithic would be more heavy-handed leadership, and the leadership is in one place controlling the whole piece. Whereas composable architecture is more like a democratic government, if you like, with smaller pieces. So when you are moving from this monolithic type of managing to a composable architecture, it is important to think that the way you manage these projects is different. It's a bit like putting a democratic government into a country like China. You know, it doesn't necessarily work straight away. So you also need the right types of people, not just the architecture. You also need the right types of people to make sure that it works.

And I guess with composable teams, it comes with management as well. They come in a complete package. You have different, let's say if you hire a composable team, they have their own management at the same time as opposed to a big monolithic team where you'll be given a project manager from another team that doesn't have any background with a feature. Whereas, in a composable team, they've already been working together.

It's no different from verticals, product verticals, feature teams, composable teams are basically that they are the <laugh> agile best practices, if you like. But with any composable projects, and I'm sure this opinion is shared by many who espouse composability, is that there has to be ownership from the brand or retailer that is implementing composable. What I mean by that is that the ideal scenario should be that you've got the brand or retailer having control of the program, mm-hmm. <affirmative>, and then they hire a composable API. You know, they select a composable API and they select a composable team, you know, but they control the program. Mm-hmm. <affirmative>, I think those are the, that's the most ideal situation to be in. The less ideal situation to be in is an organization that is not mature technically but chooses composability, that they have composable technology, but they have monolithic people. They have a monolithic structure of running the projects. And those, in my view, can work, but very difficult to make work. Mm-hmm. <affirmative>, it's again, like putting democracy in China, putting democracy with one billion people, a lot harder, you know, <laugh> as opposed to running democratic countries in the Western hemisphere.