Efficiency unleashed: The Ericsson playbook for embedded system development | Ericsson

[Conny Wickström:] So, hello, nice to see so many of you here today. Since I guess you have rested your arms from the morning exercise, we're going to do that again. So, we ask all of you to raise all your hands, or one hand is enough and keep it up. And if you work in a software company or a project with more than 100 developers or testers, keep your hands up. Okay. If you work in a project or company with more than 500. Ah, still quite a lot. That's great. And if you feel that you struggle with speed and efficiency in your software development flow. And it's okay to raise hands if you've put them down. [laughs] Okay, so that's good. We even got a few more hands up again. Great, you can take down your hands. It proves that, at least, you're in the right room, because we're going to talk about the challenges and what we have done. Not necessarily solving everything, but at least working with the challenges. And as you know, we come from an old and large software and hardware company actually. So, let's get started, and Kristofer will tell us. [Kristofer Hallén:] Some context, I'm Kristofer, this is Conny. We are from Ericsson. We are from the mobile part of Ericsson. We're making these things that connect your phone. Without us, you probably wouldn't have a connection today. So, mobile networks is what we're doing. Ericsson is quite an old company. In 1876, started out repairing phones, building some of the first phones ever. We're still here. We're a world leader in mobile networks. So, during that time, we've had to reinvent many times from cables and stuff, and now into a lot of wireless things. To give you a bit of a context, and that's also why we're asking about the size, we're working with a lot of things at large scale. So, a lot of people, a large global market. But we also work a lot on custom hardware and many different platforms to run things on. And our products are highly regulated. A lot of almost extreme requirements. You are always supposed to be able to call an ambulance if you need it. It's not supposed to go down. And we have a lot of software on these systems and many platforms, but for us, we always come back to this, it's not only software. In the end, there's always an antenna. We need to relate to the physical world. So, that's a bit of the context where we will tell the story today. I'm Kristofer, I've been a developer in both telecom and automotive, architect, but more and more I've come into development environment, CI/CD, release, supporting developers, making sure they can actually bring a product to customer. [Conny:] Yes, I'm Conny, I worked as well as a developer. I started in the 3G era, and I worked through 3G, 4G, 5G and 6G. And now, I'm mostly focusing on CI and CD and tools and building systems to support large development organisations. So, that's us. [Kristofer:] Starting with our story here today, the learnings we will talk about. We had a reason to change. Our title here is Efficiency and Speed. Somewhere 15 years ago, we were developing 4G. We ended up being not fast enough. So, we came from a situation where we had every new generation of mobile networks, 2G, 3G, 4G was developed as a separate product in its own context. Delivery of software maybe once a year. That started to change. So, product changed, we now wanted to have many Gs, generations on the same platform. We had expectations to deliver much more frequently. So, I still remember that our release organisation practically said, 'We give up, we can't handle this anymore.' They used to collect the information and mails and documents and tried to put it together. Didn't work. So, we needed to adapt to a changing reality, changing customer needs from idea to deployable value, that's also a notion of speed. How fast can you change and adapt to changed needs? [Kristofer:] Summarising our playbook, what we did during this journey, probably, we're not done and never will be, but pooling, some kind of standardising, making sure you can get things, but that they are available in the pool when testing resources, trying to find ways to decouple people so you don't have to wait for others actually bringing information, or this, making sure you know where to find the right information, and adding some culture part, especially for us, as Conny said, when we usually don't notice when things work really well. That has brought us speed and some different dimensions, and some we still need to work more on. I have not mentioned that much about tools, and we have done some reflections here. We've also gone into if there's one tool to solve it all. We've never really managed to do it, but we definitely see tools as important enablers to be able to, for example, do these kinds of things, but they bring a capability, and it might not be that it's only this, also kind of looping back, not one silver bullet, but you need good things that give you good capabilities, and of course, you can't just use anything, you still need to balance with competence and a budget to actually run stuff. And then, we're getting to the end of this. I would be very happy to have some time for discussion now, if someone wants it, or if you grab us by the coffee or challenge us or say that you would like to discuss and learn more from us. So, thank you.