Host Intro (Gene Kim)

I am so much looking forward to the next experience report. VELUX is a Danish manufacturing company that specializes in producing roof windows and skylights, and is famous for its products that bring in light and fresh air into buildings. Their commercials on YouTube are just absolutely delightful.

But I love so much this experience report from Josefin Salomonsson and Henrik Høegh, Senior Manager of Platform Engineering. I think this is such a fantastic and thoughtful presentation on enabling a product-led mindset for internal services, and thinking about internal platforms from first principles, focusing on lowering the cognitive load for internal engineers and staff. I think this is just so fantastic because they rethought about internal technologies from being a cost center to being product-led.

So here is Josefin and Henrik.

Anna Josefin Salomonsson

We are super excited to be here and to talk about our journey towards adopting a product mindset. My name is Josefin, and I'm heading up IT Strategy and Transformation Office as part of the Global IT and Digital Enablement organization. And with me I have Henrik, who will do most of the speech today. Henrik, you can say a couple of words about you.

Henrik Høegh

Yes. Hi, my name is Henrik Høegh. Very complicated last name. I know it's not universal. Awesome to be here.

Anna Josefin Salomonsson

So I'll start out with providing a brief introduction to our company, to VELUX, who we are as a company, our new strategy that sort of triggered the change for doing something different in IT.

And then I will give the word to Henrik, who will elaborate on our journey regarding a product mindset.

So, as Gene also mentioned, VELUX is a Danish company with a very strong purpose that we are very proud of: to create well-being for people and planet by transforming spaces using daylight and fresh air.

And what you see in the picture here is actually our core product, the famous roof window, which we are designing, manufacturing, and delivering to the market. And we are, and have been since actually the origin 80 years ago, the leading brand within our category.

We operate in 37 countries. We have 21 production sites in 12 countries across the world, and we employ close to 12,000 employees globally.

We recently launched a new strategy with a more explicit focus to get closer to our end customers, meaning the homeowners. So we are in the middle of a transformation from a B2B to a B2B2C company.

And for IT, this requires a dual focus and a significant uplift of our IT foundation across people, processes, and technology, meaning new capabilities to support B2C capabilities, especially within sales and marketing, a transformation towards a composable architecture and platform thinking, an exponential increase in SaaS solutions, and not least the shift in mindset and procedures from traditional large enterprise projects to more nimble products.

We have embarked on this journey across many dimensions in IT. And today we'll dig deeper into one of them, namely how we are driving this transformation from a Cloud Center of Excellence perspective and our platform engineering team.

And this team is actually paving the path for great developer experience across all our internal platform and product teams. And Henrik will now elaborate on our journey to date, and it's spanning across methodology, toolbox, and now how we have set ourselves up for success.

So I would say, Henrik, take it away.

Henrik Høegh

Thank you so much.

The first thing I want to talk about is cognitive load. And cognitive load needs to go down.

I made this drawing. It's not scientific or anything, but I think from a developer perspective, when Agile was introduced, things were quite easy. You need to stand up once in a while and deliver often, whereas it was hard for ops. They needed to have service ready really often.

Then DevOps came. And what I saw at least was that the cognitive load rose dramatically for developers. You needed to learn Ansible, Terraform, or whatever it might be.

Then came orchestration with Kubernetes, Docker Swarm, and Mesos and so on. They needed to write a bit of YAML. It was a bit easier, but then platform engineering came. That's where most people are right now, where they have a thousand applications in the ecosystem that developers now need to understand. And that's just not feasible.

So I think the next thing we'll see is experience and how we get the cognitive load down for the developers without getting it up for us or the platform team.

I think we can do that with a product mindset and by using abstractions. So I'll talk a bit about what we did in our team and some of the ways we work. We do things very differently. We have our own mind of how we want to do things. So that's what we want to share.

I really love cognitive load theory. I'm not an expert. This is my interpretation of how it could apply to an IT setting. It's from the educational system.

Basically, you have three categories. Intrinsic and germane are the two that you really want to maximize. Intrinsic is basically your skills. If you're a developer, you need to learn how to program, you need to use an editor, VI or something else.

The germane part, for me, I see it as the domain, or the understanding of the domain that you work in, and the value that you can then deliver and build upon.

The middle one, I cannot pronounce. I have no clue how to pronounce that. Extraneous or something like that. But it's basically, as I understand it, everything that's in your way, everything that's slowing you down. You need to wait for this. You need to also do this, which is not directly part of the value.

And we want to minimize this as much as possible in order to make more space for the two others, for developers. So everything from onboarding, new projects, quality control, just not quality assurance, just to put a note on that, releasing a service, support, and end of life and all that stuff. We want to take care of that and make that as easy as possible.

If we look at what many people have done, if we look at platform engineering before we look at developer experience, I see that many people look at these projects and we have these huge projects. It's mostly waterfall. There's a lot of risk. There's a lot of deadlines. It's very tricky.

And one of the ways you can attack that is with platform engineering. So you build a platform. You can be inspired by Team Topologies. And then what we have done is that we built a platform, and then we have these small projects now because we took the generic parts out of the projects and put that into the platform.

And these should always communicate via API. So there should be no handoffs. It should not be, can you please do this for me, or wait for something. It should be, I need this. You'll get it now. Or you can programmatically actually ask for it.

If you do it wrong, you can do Team Apologies, I guess. But this is where we are with Team Topologies. It should be products, but we are just not there yet. So it's just where we are.

And then of course they can continue to deliver work faster with low risk and so on.

But what you end up with, what I mentioned with platform engineering, is that you end up with this lovely toolbox with a lot of awesome tools in it. And what I see companies do is they build these and they automate it, and then they give it to developers like they were Oprah and say, you get a cluster, you get a cluster, everybody gets a cluster. And they need to now know what Kubernetes is, what Helm, cert-manager, and all that stuff. That's why the cognitive load actually went up instead of down, as it should.

So we believe that developers should describe their domain in their language only. We are heavily inspired by domain-driven design, which I'll talk a bit more about. And the platform's job is to then translate that into whatever the platform needs. It could be a VM or whatever.

If we talk about language, which is very important in domain-driven design, you can have a developer domain where they have a language and an understanding of how things work in their domain. They might use words like aggregate or instance, where we in the platform might say instances or replicas because that's the language in the Kubernetes domain. We should not bleed into their domain. So we should try to really focus on allowing them to use their language.

So what do you do in domain-driven design? If you're a developer, you know that you could have an external company, like in this case it could be something like Ticketmaster. They have their own domain with their own data model and their own data and so on. They can send data to you into your domain, but you would not put it directly into your domain. You would have this anti-corruption layer in front of it that would translate it into your language, your specification, your setup, so your understanding of the world. It could be a subscriber is a user. It could be a different setup altogether.

We were very inspired by this. So we tried to do the same. From the developer domain, we have an IDE like VI or VS Code or whatever they use. Nowadays you have Git, so you can commit. And then we made a specification. We made a Bura.yaml. Bura is a Latin word meaning sail on a ship.

And then we have Bura CLI that we are maintaining and developing. The idea is that in this Bura YAML, you as a developer can describe your service in your domain language. And with the Bura CLI, you can then transfer that into our domain, into an anti-corruption layer we call a plan. That plan can then transfer it and translate it into our CI/CD systems, or platform capabilities, orchestration capabilities, and cloud computing if we go there.

So we've been working on that. And right now we are at the point where if you need a new service, you go to Backstage, you fill out a form, two minutes later you have a Git repository with scaffolding, services, everything you need. Everything that CI/CD can do, you can do with one command with Bura. So security scan: Bura run security scan. Build a container: Bura run build container. CI/CD does the exact same thing.

And that actually empowers developers by much faster feedback, like instant feedback almost. If you need to release a service or release this version to this environment, enter, done. Five minutes later it's running in all clusters.

So what we end up with is a toolbox, which is really awesome for us, but we have a thin API on top of it for developers that they communicate with, which is Backstage in our case for portal, and a CLI, Bura.

I also want to share a bit about how we work, because we do things slightly different.

We are very distributed. We sit at home. Everybody works from home. We have five men and five women scattered across northern Europe. We have five people in Denmark. We have one in Malmö. We have four people in Riga. We just hired two more people: Linda, who will take over my old position as a platform lead, and Emma, who will be a platform advocate, which is a new position. That'll be interesting.

Yes, how we work. We do a lot of the stuff you'll find in Scrum, but slightly different. We have the check-ins. We have retrospectives. We have one-on-ones. We have review. That's not really important. We have individual preparations, so everybody gets a bit of time to prepare for the planning.

But planning, we don't have a backlog. We don't want a backlog. So planning is about verbally agreeing in the team what's the most important thing the next 14 days. That's all.

And then when planning is over, everybody creates their first task and starts working on that.

It looks a bit like this. So we have epics where we have our areas, you could say, that we want to work with, divided into queues. Under these we have our products and capabilities or components, and those are very static or stable. And under these, they start to create tasks.

But you can't really do that in a normal setting with a product owner, because it doesn't really work. So we do something slightly different.

We don't estimate tasks. We don't calculate velocity. We don't calculate capacity. We believe that's a waste of time. We would rather know our customer, talk to our customer, understand our customers, which are the other developers in the company. And then we want to do the important things first.

It only works because we distribute ownership.

So the team, this is a bit technical, but the team is the CCoE. We have a platform owner. We then have domains or subdomains, if you want to use that. But we can put an owner on these as well. Here we have the developer experience on the platform domain. Under these we have products. So you can have an owner of a product. So each of these have an owner. So Bura is owned by Linda.

I actually came to her and said, I have this great idea for a feature. And she just said, no, it's a bad idea. And that's good. That's how it should be, right? So they can make decisions. That's why we can do planning so fast: 15 minutes. Everybody knows exactly what they need to do in the next 14 days because they own it.

And then we have components or capabilities. You can have owners on that as well. And we have interfaces. If we need to scale the team and split it, we can do it by domain. We can do it by product. We can even do it by component. We don't have any tight couplings.

So building a product, we have no external stakeholders. Nobody is telling us what to do or how to do it. We talk to our customers as if we were a company within the company. We understand their pain, we try to fix it with technology, and we build feedback into our products. So we have a new project called Panko where we try to register everything that's done. And we love our customers. Some people say customer obsession. We are not quite there yet, but we love it. Let's put it like that.

We try to convey strategy. If you know Wardley maps, I don't have time to go too much into it, but this is our current state before we started with developer experience. So we communicated that we needed a portal that will communicate with Flux. We needed a CLI, in this case Bura, which has some connections to both GitHub and Artifactory. And the user depends on it, of course. Bura has a couple of components. You can group them and then you can visually say, I want to invest in moving this to the right. So mature it: this is our investment. GitHub would go down visibility-wise because Bura would take over a lot of those features. And we want to invest in our on-prem distribution because it's not that mature. So Wardley maps are really good to convey strategy and investment.

We don't have a lot of metrics yet. We are working on it. But one of them we have is number of releases. And from this you can see December, people work off for some reason. But we have a good steady growth of adoption, I would say. We had like 1,200 releases in the last 30 days. And that's only in our cloud environment right now. We have 18 on-prem clusters as well, which we are enrolling in this.

So we want to take the learnings from this team and try and share that with other teams. The easiest products you can do, I believe, is a platform because your customer is yourself, which is the easiest customer in the world.

So we have a data platform now, or are building, and we have a web development platform. So in this case Sitecore. So we want to empower everybody who uses data, everybody who needs to build a Sitecore website. So Sitecore as a service or something like that.

If you have any expertise in this, we would love to hear from you, what you think about what we said and what we shared. We're also hiring, of course, like everybody else. But yeah, that's our story. I hope I didn't talk too fast. But yeah, that's it. Thank you.

Q&A

Gene Kim: Fantastic. Josefin, is there anything you want to add in terms of things you're most proud of, or testimonials that you've heard that make you happiest? Either Henrik or Josefin.

Henrik Høegh: We talk a lot with especially [unclear], which is our biggest customer right now. I really wanted a slide with some testimonials, but it's been a hectic week. I didn't get it. But basically they really like our product. They love the ideas that we have with Bura. It simplifies things. They can see the value that we remove all these complexities from them that they don't really care about. What is cert-manager? I don't care. I need to get this value to our customers, mate. So yeah.

Gene Kim: Super. Yeah, I love that, by the way, that your cognitive load slides are like, these are all the things that no one cares about, especially developers. Yes. Okay. Fantastic. Thank you, Josefin and Henrik.