Developer freedom vs editor needs: How Sky Group balances both

Jasmin: [00:00:00] We often talk about digital transformation being important for happy developers, but why is that? Technology is meant to free developers from boring maintenance and manual tasks. Giving dev teams time to focus on more exciting and valuable ideas like innovation, what does that really look like in practice?
Our guests from media giant Sky Group have cracked the code to developer freedom. The team behind the award-winning Sky Websites project is here to share how they've built a culture of everyday innovation for their developers and how exactly that works. You're listening to People Changing Enterprises.[00:01:00]
I'm your host, Jasmin Guthmann and please enjoy this episode with Richard Mace and Oliver Cavanagh, Product Manager and Lead Developer at Sky.
Richard: We've worked together for quite a long time. I've been at the business for five years and I've worked with Ollie that entire five years. Ollie's journey is interesting.
Oliver: Yes. I've been at Sky, think this is my ninth year, so I joined them on an apprenticeship scheme, so I straight out school at 16. My entire career has been at Sky, started off as apprentice, working on internal applications and just went through different projects throughout the years.
Oliver: Sky really does give people freedom like so many people gone off and spun up their own teams because they had an idea to do this thing.
Richard: That's what happened with us. We were within one other team where we'd started building this project, and now we've been spun off into a different team that is in a completely different part of the business, and we were given the freedom to then hire our own team. So we've really taken ownership of it over those few years. It was a pet project for us, and now it gets to be our full-time, which is just perfect.
Jasmin: You guys have quite a unique [00:02:00] culture at Sky UK where you're able to truly give developers freedom to innovate. Can you tell me more about what that actually means and how it plays out in real life?
Richard: Yeah. I think when I joined Sky, having worked at a tech startup before and seen that the way that they approach things, I came in with that attitude of thinking, this is gonna be a bit of a behemoth. It's gonna be hard to navigate, it's gonna be hard to get anything done. And it was hard to figure out how everything worked.
But the director that we had at the time in our technology function really emphasized trying to have that startup culture. Within the technology function. So from a technology point of view, she wanted us to have that attitude of be bold and be brave, and let's operate in a way that a startup would operate and push ourselves.
I think we're really lucky in our team that we've got developers who are quite self-motivated to do that and to see improvements as they go. We have the freedom to think in a truly agile way and to shift our focus if we spot something that we know we need to, that we want to work on is gonna provide a lot of value to the platform.
So it is really allowed us [00:03:00] to be a very adaptable team.
Oliver: Yeah. I think with freedom to innovate, if you give people that freedom and remove the shackles and trust people, that's where your magic really starts happen. So I think our culture is really about if we can innovate, let's bring that to the day-to-day.
Richard: Yes. Yeah. It happens when you're not expecting it, you can't schedule in innovation. Yes. Is one way of putting it. So we've got a couple of things in our culture that I think that really help with the innovation. We've got a real culture on the team of if you see something that you're not happy with and that you think that we could improve, bring it to the table and we'll bring it into our sprints.
We have a very collaborative approach to the work that we do. We have a culture of doing spikes in our sprints. Go into a bit of an investigation, see what you can find out. We'll maybe time box it for a couple of days, present it to the team, and then we can have a discussion about that and see whether it's something that we can bring into the platform. So I think having the freedom in our roadmap is one thing that helps and having that culture within the team. And then there's another thing that we do that is quite unique is we do something called Boost Time. Our Friday afternoons in [00:04:00] our calendars, you're not allowed to put a meeting in there and you don't do sprint work during that time.
That's the time for you to do some learning on something that you are interested in that's gonna help you in your job. Maybe something's a little bit different from what you do, whether it's listening to a TED Talk, whether it's reading about a particular kind of coding that you've not done before, anything you like that can help broaden your horizons.
And I think having that culture has then allowed people to think, I'm not gonna accept the status quo. I'm gonna learn about something that's different and I'm going to challenge the status quo.
Oliver: I guess the other thing that we've really done to kind of help this is really getting our developers to buy into the platform.
So I think they really see that as their own products and that they can make change. So they really have that sense of ownership, that they want it to be better, they want it to be the best possible product they can, and I think that's what really fuels and drives that innovation. Something we try to do as well is if someone has done something is, bring it back to the team, showcase to everyone, talk everyone through how you've done it, what you've done, and that kind of inspires the next person to go, [00:05:00] ah, off the back of that, I'm gonna go try this. Or maybe gives them a bit of a different perspective on how that person's tackled it. And yeah, it really, again, drives more innovation.
Jasmin: How do decisions get made when someone pitches an idea? Who gets to decide if something is built?
Richard: A lot of ideas that we've done over the last few months have come organically from the developers, either from things that they've been looking at or an editor said, I want to do this. I want to try and achieve this.
And then we've gone away and had a look at it and thought, actually there's one way that we could do that might maybe changing this particular feature or creating this new feature. So it is an organic and collaborative process. We have a roadmap that is loosely defined for the year. But one thing I found is that the best-laid plans don't always work out.
As long as we've added value to the platform, we are happy. And so if an idea is brought to the team, if we can demonstrate that it has value and we think it's worthwhile doing now, there's nothing else that's maybe a higher priority, then we add it to our sprint.
Oliver: Because everyone's got that self kind of ownership of the platform,
we almost don't [00:06:00] have to make anyone make decisions as such. Like we come to a collective like, oh, this seems like the right thing to do. And I think so far it's worked out. We've got a product that's doing great and we've got some great features out of it, and I think sometimes just looking for someone to make a decision can almost be the problem.
Richard: We have guiding principles, and I think that helps the process is that we have guiding principles. The guiding principles being that this should be a platform that anybody can use. We want to keep it simple. It needs to be user-friendly. And so that's, I often come in that sense, as a non-developer, I can provide a perspective of the users and the editors.
I speak to them probably more than the developers do, and so I can often challenge and say, are we making things simpler enough? Is that gonna be user-friendly? We want things to be quick from a developer point of view. We want things that are gonna be scalable and automatable, and if it fits those sorts of guidelines and principles, then we're happy with it.
It's probably gonna be something that we all agree is right.
Jasmin: Sounds like you're the bridge between the editors and the [00:07:00] developers? Help the listeners understand how that collaboration works.
Richard: I can almost be like a salesperson for the platform, so I go out there and try and get business from people across the company.
So I engage with them quite early on and it is a bit of a sales pitch. I present, here's what our platform can do. We'll do a demonstration or maybe even mock up their existing site in our platform and show what's possible and take it from there. And sometimes those discussions can be, I like what you've done in that demonstration, but I'm not happy with X, Y, and Z.
And it is a very open and honest conversation. But to say, I think that does fit into the guiding principles that we've got for the platform. We will look into it and we have the freedom to then add that to our roadmap. Or I can say, look, the model that we're going down that doesn't really fit what we are trying to do.
Jasmin: Is there ever a case where you have tensions? Do you ever experience your editors and your developers going head to head and saying, yeah, but I want this and the other side saying, no.
Richard: I'm definitely the bridge between them. So we don't let the editors talk to the developers directly too much. They do meet them, [00:08:00] and I do joke, but I don't think we have too many tensions because we do recognize that the platform is not right for every particular use case. So there have been some discussions where we've had that sort of sales pitch and they decided it's not right for them. And often I'm quite easy with that. That's, that just may well be the case. It doesn't necessarily fit every use case. We've not had too many tensions because often if we can have that sort of rational discussion with somebody and explain why the suggestion that they've got doesn't fit our guiding principles, then generally that's been accepted because we can have that rational conversation with them.
And I think it maybe helps with me not being a developer. I understand the technical side of it, so I can have that appreciation of it, but I'm not a coder. I can't write any code. But I can appreciate the business side of it and the editorial side of it, and have a conversation with them that will hopefully see from, they will understand the perspective that I'm coming across with.
And so I've not really had tensions with any of the editors at all. It's a very collaborative process and I think that they're really happy with the platform that [00:09:00] we've provided to them.
Oliver: I think as well because we've got that flexibility in our roadmap that gives us a lot more power from in the past where we might have gone. We can do that maybe in three months time. Like we go, you really want that? Cool. Give us a week or two. We'll do it. That makes them happy and they have a bit more. So I think like that relationship has really improved from that perspective. We're only really speaking to them when they've got a new, exciting idea and we kind of, we'd love to learn more how you want to use it.
So that dynamics really changed from being right there and now trying to, I need to get this live to fix this problem to more looking, more for futuristic and going. What is it that you want? How do you want that to work? Or how can we make our platform better for you?
Jasmin: And I love the clarity, and I think that's what your editors probably appreciate as well, right? You're very clear. You have your guiding principles in place, and they're not a secret, I take it. They're out there in the open. People know how you're operating and how they can benefit from the great work that you guys do. Any final [00:10:00] advice that you can give for people who are looking to encourage more freedom, more innovation, happier developers within their businesses.
Richard: I would say give the developers the freedom and the time to think about innovations and to work on them. Bake some time into their weeks and their months so that they can have the time to experiment. You're not gonna get that innovation without the freedom to think and the sort of the head space to think outside of the box.
If you are bogged down just with BAU, you're never gonna start to even daydream of what's possible and have some time in there for them to experiment, do investigations and proof of concepts and trust them as well. When an idea comes up, trust them that it's, that it might work, sometimes it won't.
Sometimes a proof of concept comes out and says it doesn't really work out, and that's fine. Failure is a pathway to learning. It's a step on the journey, but give them that freedom, that time. I would say.
Oliver: [00:11:00] Completely echo that. I think trust is a big one. Your development team are the closest people to the product. They know it better than anyone else, so go with their instinct. If they think the product needs to change, like they're probably right.
Jasmin: Thanks for listening 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.