Back to podcasts

From frustration to freedom: The Sky Websites revolution

November 12, 2023 / 19:34 / E43
Download
podcast-bg
Sky is one of Europe's leading media organizations, and since going composable, they've created a revolutionary way inside the business for content editors to create and update websites without involving developers. It's called Sky Websites, and it won the Contentstack Experience Awards in 2023. Project leads Richard Mace, Senior Product Manager and Oliver Cavanagh, Lead Developer, join the show to talk about how Sky Websites was created, how it's helped to both developers and content editors work more effectively, and what hurdles had to be overcome to make it happen.

Timestamps:


01:22 Richard, Oliver, and Sky Group introduction
02:14 The drivers behind composable transformation at Sky Group
03:39 What is Sky Websites?
05:37 A composable content model POC
06:58 What impact has Sky Websites had on the business? 
09:40 The hurdles of changing mindsets and challenging the status quo 
12:36 Why it's important to be able to let go of your work
13:25 Why composable is essential for the Sky Websites project 
15:15 The importance of small steps - transformation won't always go smoothly
17:49 Setting yourself up for future success

Jasmin: [00:00:00] Sky Group is one of Europe's leading media companies, and this year they won the Contentstack Experience Award for Most Innovative Project with their incredibly clever no code solution called Sky Websites. This project has changed the game for both developers and content creators.
Oliver: It was not easy to get a website. It probably took a good couple of months to kind of get your work scheduled in.
Jasmin: It's no small feat to transform web development in any company, let alone an enormous media enterprise.
Richard: And there were lessons along the way. I think it's important to remember, like it didn't start out at the very beginning with all of that mapped out in mind, and then it's gone very smoothly and very linearly. We've learned along the way.
Jasmin: Richard Mace and [00:01:00] Oliver Cavanaugh, join us on the show today to tell us about the unexpected challenges, the eureka moments, and the strategies that turn frustration into freedom. You're listening to People Changing Enterprises. I'm your host, Jasmine Guthmann, and please enjoy this episode with Richard and Oliver from Sky Group.
Richard: My name's Richard Mace and I'm a senior product manager at Sky, and I manage a product called Sky Websites.
Oliver: My name's Oliver Cavanaugh, and I'm the lead developer for Sky Websites, and so I look after the technical direction of that product.
Jasmin: For those of our listeners who might not be familiar, tell us a little bit about Sky.
Richard: Sky is one of Europe's leading media companies that provide premium TV services, broadband and mobile services. Sky's been around for quite a while. International listeners might be more familiar with Comcast. They bought Sky in 2018, so part of the Comcast NBCU family.
Jasmin: Fun fact, I used to have a Sky [00:02:00] receiver even. Sky was one of the first products that was available in the German market, so
Richard: Right. There you go. Yeah.
Jasmin: You've been on the ground for the composable transformation really at Sky. Tell me what happened. How was the decision made to go composable? And what it's been like.
Oliver: I guess it's really started out with frustration and I think both on the business side and the developer side. Sky's quite a fast-paced moving brand. We've got new products constantly and kind of when we were doing for a composable world, we were able to react to that change. It usually take us, at least at best case, two weeks to make a change. That really an editor should be able to see themselves, but they're often to come to developers.
Richard: Yeah and, and remembering those early days, the team that Oliver and I were in we're sort of, we call ourselves a digital agency.
We were an agency within Sky who would do work for various different teams. And, and so we had to, had to build those teams to the kind of work that we did, and we found that some of the work that we were being asked to do, the costs were [00:03:00] quite high and it was difficult to justify and we were sort of competing with third party agencies who could be quite agile, who had lots of templated solutions.
And we find ourselves losing out on business to third-party agencies, which looking back on was crazy because it was spend that was leaving the company and, and it didn't really make sense. And we knew that there was, there was definitely a different way of approaching what we were doing. And I have to clarify that it is just specifically for the, the area of the business that we're in.
There are other parts of the Sky that haven't gone through a, a composable transformation and maybe it doesn't necessarily work for them. Uh, but certainly in our area, it made so much sense to go down this more composable route to make the solution a lot more agile and to make it a lot more cost-effective.
Jasmin: Let's take a closer look at Sky Websites 'cause I know that that's something that's been a huge success. What is Sky Websites and what was the origin story of the project?
Richard: Sky Websites is a platform for allowing anyone to create Sky-branded, content-driven websites quickly and easily. So there's a few different parts to that.
It's a [00:04:00] platform, it's not a website. It helps you to build websites. It allows anyone, so you don't have to be a developer. You don't even have to have web design experience. You don't need to be able to write a line of code to create a website. We market it as like Squarespace for Sky. I think it might be worth telling the story of how the platform came to be and then see the journey that we've gone on.
So originally our team, as we were that digital agency, we looked after Sky's corporate website, which is SkyGroup.sky, and that was built using Contentstack as its CMS. But every page was its own defined piece of content. It was its own content model with its layout defined in the content management system.
But then editors, editors had the ability to decide what was gonna go in all of the different sections of a, of a particular page. So if you wanted a new page, we'd have to create a new content model for that page. Define it, define it in our code, and then it was available in the CMS for them to edit.
And that's the model that we really wanted to break. It was very frustrating that to create a page took three days and we, over a period of time, got frustrated with that. But [00:05:00] then we were, we were asked by the business that they wanted to completely redesign the site. We're always constantly evolving our look and feel.
We always wanted to look fresh and new. And so they said, we want to redesign all of the 50, 60 pages that we have on the site, change the information architecture and how we are arranging everything. What's that gonna cost? They asked us, we gave them a figure that led to lots of strained looks and wow.
Okay. But I mean, it was, it was a figure that we were willing to spend it, you know, it was something that we figured that we were gonna have to do. And that's when the team said, well, actually, there might be another way. It might cost a similar amount of money to do this thing, but hopefully, it's gonna save time in the future.
So that's when we went down the route of creating a POC for a composable model where instead of every page is its own content model in the CMS, there is a content model for pages and you can create as many pages as you'd like as entries, and then the creation of the content on the page is done through module blocks, components that you drag and drop into the CMS so that you can build the [00:06:00] pages, you can build the layout of the page yourself, as well as what content goes into it.
So that in three months time, when you want to change that button to say something different, you can make the change in the CMS, but if you want that button to appear in a different place in the page, you can drag and drop it. If you want to remove something, add something, you can do it yourself. It's a process that shouldn't take days and days to edit content.
You can create a page in a matter of minutes, uh, hours depending on how complicated you want to make it. And easily. You don't need to have any special skills. I train people on how to use the platform and it takes me about an hour to train them. And then you can go ahead and create as much content as you want. And it's intuitive enough to create a whole website.
Jasmin: That's amazing and it's, you're really removing that barrier that still exists in many companies, where nothing is ever easy or quickly done if you're in marketing because you have to open a Jira ticket. And then a poor developer annoyed as heck is like, oh God, you have to be kidding me. What a typo? How has that been received [00:07:00] across the company?
Richard: So we did that proof of concept to show, well, this is what we could potentially do. We built it as an MVP with a very small set of components. There was only a limited amount of functionality it could have done. I'm sure if we've done all of the pages sort of ourselves, we could have made it look a lot fancier, but two years down the line, they would've had to have spent a similar amount of money to change it.
But we created this platform, we gave it over to the business. They were able to launch the site on the platform. And then about a year later, we discovered that the team, the corporate comms team who look after the site had created 20 brand new pages and replaced a whole section of site, probably half of the site that they completely redesigned and never told us because they didn't need to.
It wasn't something, and that would've been, that would've been months of work for the development team to do, but they could just do it, um, themselves.
Oliver: From a business perspective, it was not easy to get a website. It probably took a good couple of months to kind of get work scheduled in it. If it was a priority. And then equally you'd have to get funding.
That cost would [00:08:00] usually be more expensive than going external. So I think from a business sector, we've really knocked it on our head 'cause we've kind of made it very as self-service possible. And we can create a site now on a test environment in little as an hour and then to get that ready for production.
A week or two, we can get that live. So we've really turned around kind of the speed from months for maybe a couple of changes to, you can have a full website, which you can build, start building within a couple of hours. So I think it's, yeah, it's definitely been very well received from that end. I think what we're really trying to do as well and really helps our stakeholders, so they don't know about compliance, security, or even stuff like accessibility.
We take care of that for them so they don't have to worry about it. So all they do is they go, Hey guys, I wanna use your platform. We set that up and then we take care of everything. So all our sites are accessible, compliant, secure, so we can really drive that consistency on the standards that Sky expect without our, um, business stakeholders have to worry about that.
Richard: Yeah. And it's that central platform as well, so that as we're [00:09:00] evolving it, if you have a website that's on our platform and we may be onboard another stakeholder who has some different needs and new requirements, and we build some new features for them. You get those features sort of as a matter of course.
It's a constantly evolving and improving platform that you can benefit from if you join it. I think we used to say three days to make a brand-new page. So you can imagine that our Jira board would be filled with lots of BAU work that was amending the layout of pages as we're, as we're sort of tweaking things. Now our Jira board is made up completely of improvements that we wanna make to the back end of the platform, adding automation and adding new features.
So in the last six to seven months, we've added probably more features than we have in the last sort of, uh, two years prior to that.
Jasmin: What were some of the hurdles that you faced, expected and unexpected?
Oliver: I think the biggest challenge was making, helping the business understand that we needed to make a change. Obviously, with any change there's always, it's always gonna go back to cost, this takes time and money and that's always a difficult thing to kind of convince the business. So we've spent a lot of time [00:10:00] ahead of this kind of before we made this journey, making sure that we have the data behind it. So we run lots of surveys with not just developers.
But also the business kind of understand the different perspectives of, A: what what do people kind of think of the existing solution? What are your pain points? And equally, what's your perception? Because I think on our previous solution, our stakeholders had this kind of mindset that it was this all singing, dancing platform that was amazing that they did all these things, when in reality it was a great platform, but it didn't do half the things that they thought It.
And I think the other bit of data that was really helpful was quantifying, so kind of thinking about how long build times were on the previous platform, that was quite expensive. I remember we used to say, if you wanna do a build, you'd have to go get a cup of tea because it took that long, which is just, just not sustainable.
So I think for us, the hurdles was making sure we had a lot of that data so we could convince the business and kind of really make that justification. And in the end, 'cause we had, I believe, 'cause we had all that data, we were able to go to our, head of technology at the time and go [00:11:00] look, give us two months to kind of POC something together and let's see what happens.
And I think that really unlocked something that Richard, kind of quite big believers in, is giving people freedom and to kind of innovate and 'cause that's really where the magic happens when you kind of let people free.
Richard: I think what Oli said about finding that data-driven answer to the question, realizing that what you're doing is not the best way of doing it.
I've worked in lots of businesses in my career so far, and I've come across a lot of situations where people say, well, that's just the way we do this. And just accepting the status quo. Sometimes it takes a little bit of bravery to think, well actually we're gonna, we are gonna spend a little bit of time upfront to make something better or just to even recognize the fact that what you are doing isn't ideal.
So example of the build will take so long, you've gotta go make a cup of tea. Some people might think, oh, that's great. That means that I get to have some time in my day that's artificially put in there for me. But others would say, well, no. What if there's other things you'd be able to get on with? What are ways that we can recognize when something isn't ideal?
And I think that was really important. And some of it came from developer frustration. Some of it came [00:12:00] from editor frustration and, and our stakeholders. And some came from just the raw costs when we were asked to do a piece of work. We estimated a number to our stakeholders and said, that's how much it's gonna cost for the budget.
And then realizing as well, that thinking beyond just that initial piece of work, and I recognized that we were probably gonna have to do that same piece of work again in a few years time and sort of thinking about a sustainable solution. How can we not only avoid spending this particular amount of money right now, but how can we make a sustainable solution that's gonna mean we never have to do anything like this again?
That we have something that is. Is future-proofed.
Jasmin: Love that you say that. If you wanna become better at what you do, you need to be able to let go. You need to acknowledge and admit almost that something that maybe you've personally built a while ago, no longer serves the initial purpose or is just not the, there is a better way of doing it.
Oliver: Yeah, definitely. I think it's from the developer commandments. It's like a [00:13:00] famous kind of medium article and one of the points it mentions is you are not your code. You've got to remember like what you've done at that time is the best that you could with the knowledge and tools you had, and you might come back to that six months with a whole different perception, experiences and do something completely different and better.
I think it's really important to constantly evolve and if change like inevitable and you've kind of got to embrace it if you're not going to embrace it, you're gonna get left behind.
Jasmin: And how important is it that your platform is composable? That is API-based?
Oliver: I think it's increasingly becoming more important. It really allows you to kind of take a very modular approach to your platform. I think technology has evolved a lot and back kind of early on in software, you'd have kind of an update you need to do and we also need to update X website as well cause that's tightly linked and we also need to do that. And then something that should be, maybe a couple of days could end up being like a six-month-long project. So I think going with compostable makes sense. Like why should you [00:14:00] have to, if you've got a car, like why would you swap out the whole car? Just your tire's got a pop in it. You just want to swap out that bit of functionality.
We can now almost just swap out the bits we need to, we can upgrade our system and we're not gonna have to almost hope, not at least, but not do a big migration again to a new platform because this platform should be able to grow and evolve. So as technology grows and evolves, we can then shift with it.
It may seem expensive and scary doing composable, but I think compostable doesn't have to be a big journey. So try and think about what small steps can you get to take there and you'll get there and it will take time. It doesn't happen overnight, but the sooner you can change that mindset, it'll help you. Like, we've now built this product, oh cool. We've got these amazing features. Now let's go. Like for us it's, oh, we've built this product that works really well. But then it took a sideline for three years. Like we didn't really, I think we had three or four sites on it, and it didn't really grow. It didn't really, it did get neglected a little bit, but I think then we came back to it.
We made a lot [00:15:00] of improvement. Thankfully, the way it was architectured made that a lot easier, and now it's really grown.
I think, we managed double our site base in a year almost. There will be dips, like you don't go on this smooth journey like we've had this on pause, but eventually, in five years it's got there
Richard: And there were lessons along the way. I think it's important to remember like it didn't start out at the very beginning with all of that mapped out in mind and then it's gone very smoothly and very linearly, we've learned along the way. I think the lesson of that sort of hiatus that the project went onto and that was just a natural thing that had to happen.
There were other priorities in the business that our team had to focus on, and there wasn't a dedicated team to this platform but, it did go to show that if you make a transformation like this, you do have to invest for the long term. You can't just make it a project that happens for six months into a year and then say, we've achieved it and we've done the thing.
Dust yourself down and then go on to something else. It has to be maintained. Websites and code, they do get stale and old after a while if they don't get that care and love and attention. And so when we came back onto the project, [00:16:00] we found that there were a lot of things that needed to be updated. There were a lot of things that needed to happen before we could even start building any features.
We had to spend a good couple of months just upgrading certain things just so it was in a position where you could start working on it. And the same goes for lots of programs and lots of technical programs if you don't give them that, that care, love and attention consistently, it gets harder and harder the longer you leave it to go back to it.
So that's certainly one lesson that we learned and that's changed now. We are now a dedicated team, we just work on this platform, so we would never get into that situation again. But definitely, you can't consider it to just be a fire and forget the end of the project. We've done our transformation and we're all good.
You have to keep consistently growing it and evolving it. So it wasn't quite that natural linear journey. We did have sort of bumps along the way, but it was good that we recognized where, where we wanted to be, which is where we are now. It's not necessarily what we thought at the start. We were just doing a, a project for one particular website, but then as time went on, the business said, well, there's this other site that we have that is with a third party agency, and they're charging us an [00:17:00] astronomical amount of money to do a simple change.
Could we use the same solution that you've done on that other website? Yeah, I think we can. And we proved that we could do, we could have two sites and we could have three. And as we've built that out, we're now on 10 sites on the platform, more in the pipeline, and it is now one single platform. We went through that pain early on to help us to have a sustainable, let's look at what this is gonna be like in five, 10 years time.
Let's not just look at what things are gonna be like for the next year. So yeah, it wasn't that linear journey
Jasmin: And it never is. And I love that you kept that, open-mindedness. And I think that's why going composable or having a composable tech stack is becoming more and more important these days. You don't know what you will need in five years time. If anybody tells you something different, they're lying.
Richard: Yeah. We don't know the capabilities that people are gonna need in five to 10 years time, but I think that the model that we've created gives us the flexibility that we can add things.
And as I said over the sort of last year or so, [00:18:00] we've really been able to focus on adding features and improving the backend of the platform so that it is, it has improved astronomically in that, in that period of time. 'cause it's been able to have the focus on it. It helped us to have the freedom to build those other features because we changed what BAU was for developers.
BAU stopped being developers, build pages and started to be developers, improve the platform. Developers add automation and they add features. They're not doing the same maintenance and creation of content that they were before. Content is created by editors, not by the developers.
Oliver: Yeah and I think it's really like utilizing developers, what they're for
'cause like developers are expensive, right? Like they're not cheap. So like why have your developers doing content editor stuff? Developers should be doing the stuff that's pushing boundaries, that sets your company apart from your competitors. I think you give developers that freedom, the chance to kind of, you see that spark in their eye almost kind of when to see, oh God, I could do this and that's where you end up with cutting edge features.
Jasmin: Thanks for listening [00:19:00] to People Changing Enterprises. This show is brought to you by Contentstack, the leading composable digital experience platform for enterprises. Got a question or suggestion, email us at podcast@contentstack.com.
If you like the show, please leave us a rating or review on Apple Podcasts. We'll be back next week with a new episode, helping you make your mark.

Share on: