“Open dialogue is a must”: Eileen Mandir talks about setting up agile teams at moovel
Eileen Mandir played a pivotal role in the first stages of setting up agile project management and self-organization at Daimler. From 2012 onward, she provided the input of a transportation expert before shifting into the role of Head of Product & Lab in 2014 at what was then called Daimler’s “mobility brand”: moovel. The project was then spun off into a standalone subsidiary, a kind of corporate startup living by the principles of day-in day-out innovation and born with the DNA of agile working. Eileen’s role was to develop the moovel platform and keep it moving forward. The goal was clear throughout: to develop a mobility platform that would become the most popular app and companion for traveling around in German cities. Eileen now works as a freelance coach and consultant, advising a variety of clients – from startups to major corporations, travel companies, and regional authorities – on the topics relating to digital business models in the travel and transportation industry. In parallel to this, she also coaches clients on leadership and innovation.
We spoke to Eileen about her exciting work at moovel, a unique opportunity to hear first-hand about the challenges that arise when setting up and organizing agile teams. Eileen was also willing to share some of her insights into and lessons learned in leadership and hiring agile teams. Enjoy a paramount example in corporate innovation.
Lisa: Hi – we’re delighted, Eileen, that you’re our guest today at CODE_n SPACES and we can’t wait to hear what you have to say about corporate innovation and agile team organization! Let’s start at the beginning. How did you get involved in the Daimler moovel project? Were agile processes already a big thing at the company at that time?
Eileen: I was working in IT at the time, in the department that developed the car2go concept in 2012, which was ultimately spun off. I then moved on to the moovel project and was appointed Product Owner in the backend software development team. At the beginning we weren’t entirely that knowledgeable about scrum and agile working, so I then had to climb a pretty steep learning curve but I learned a huge amount. This was all going on around the time that a lot of agile projects were still getting off the ground and there were two camps. In the one camp there were the long-established architects. The new approach was really quite foreign to them, but suddenly there were all these scrum people running around.
Then another difficulty came along. Agile methods like scrum were known by the company at the time, but it wasn’t wholeheartedly living and breathing the actual values – the values behind the method. Agile working – organizing your own work – often grinds to a halt when it reaches the outer walls of the team. After that, the hierarchy and the company structures click into place. The software development team was working along agile lines, but the company wasn’t yet. And this is a transformation we’re seeing in a lot of places at the moment – agile methods and team leadership are making inroads into management circles.
I was Product Owner so I was the first port of call for technical issues in the development team. But suddenly the size of the team shot up and as things moved forward HR responsibilities came on top. I found myself in a continual phase of learning which I like to call “being a teenage manager.” I felt like a teenager who was practically growing an inch every night, so I’d wake up the next day faced with the same problem again that I was banging into things because my body was bigger! The new tasks came along before I had time to get used to them. It was an inspiring time and it was exciting – for me and the team. And then came the point where we decided to spin off, found a subsidiary, and set up moovel as a corporate startup from scratch. In the first month, the only thing that really worked as a process was the payroll system. Within no time, we’d set up the company as a digital subsidiary of Daimler, from a compact team in the lower two-digit range to a workforce of a good 120 people in four locations. I was also responsible for setting up a small innovation design lab, which we called the moovel lab. There was definitely a lot of passion in the project and aside from the exciting projects, it became a petri dish for team culture. It was an exciting journey, lasting years, and it changed me a lot! It also gave me the opportunity to experience close-up the kind of environment that needs to be created to facilitate innovation.
Lisa: It sounds like it was exciting, and it was a steep learning curve! What needs to be in place for innovation to happen?
Eileen: I actually believe it’s relatively simple. For a start you need talented people working in a culture of collaboration, which all believe in. But then you also really need certain protection barriers from management. Innovation needs enough space for things to unfurl – in the way it happens in CODE_n SPACES. Having KPIs at the beginning is totally out of place.
Lisa: So how did you gauge success?
Eileen: At some point it just started working for us (laughs).
Lisa: Even better!
Eileen: I’ll talk about the moovel lab and use that as my example of a source of innovation. Of course, we wanted to measure success in the long term and quantify it. So one method we used to measure things was media reports. But with lots of things, you can’t just go out and measure them – like image gains or the awesome knock-on effect the lab had on our employer branding. One of the reasons we managed to pull in a lot of leading developers as an employer was not just that we had successful products, we were also prepared to put innovation projects in place without even knowing if they’d actually succeed. This was where the moovel lab played an important role. On a superficial level it didn’t look like they were connected. It was only when we sat down and talked about it afterwards that it came out. But of course there were lots of other problems and lessons to be learned. It was these experiences that brought me onto my two main areas now: innovation and company culture.
Lisa: What barriers did you run into at the time and how did you overcome them?
Eileen: We didn’t set up moovel as a startup, somewhere on a greenfield site. Our task was to extricate an innovative topic from a major corporation – or construct – and free ourselves up. We had to struggle with a huge number of barriers transferring existing workers to the new organization, especially at the beginning. It’s not easy setting up a new team by extracting them from a company. You have to take an existing team with you, on an emotional and a practical level. You can’t simply make a decision from one day to the next, like “You’re switching companies now” or “Tomorrow you’ll be in a new position.” It takes many rounds of discussion. Of course it’s important to keep the know-how going, but it’s also important to keep up people’s passion for working together when you spin off a company – but at the same time you have to take people with the right mindset with you. You have to make sure the new company culture is tangible, from the word go. For example one thing we did was to make a clear statement, so in the new firm, company cars were replaced by a mobility allowance. Ultimately, the thing that’s crucial is getting the right mix – some of the old hands, but with a breath of fresh air. You also need new people who’ll come at things more naively – in a positive sense.
You have to make sure the new company culture is tangible, from the word go.
Lisa: So that means you knew from the beginning that the right team mindset would be an essential part of success?
Eileen: Absolutely. Hierarchies work excellently in a settled and well-known market. When you’re dealing with major levels of uncertainty, which is exactly what you have with innovation topics, you need more flexibility and agility. To put that in place, leadership has to work differently and you need to allow people to take more personal responsibility. We knew that. It was extremely important to us, right from the beginning, to have the right conversations with applicants inside and outside the company. That way we could ensure we were talking to people who were driven by the subject matter. One important thing we learned is that with agile leadership a lot of things are solved through the community and dialog, not processes. It’s also important that everyone understands what you want to put in place and that you make decisions based on that – what sort of people are needed, with which skills, which mindsets. This all has a lot to do with the culture. We took the agile team organization at Spotify as a role model and gradually made a replica of the method with our own live project over the course of two years, based on an engineering model. So there were self-organizing teams and squads. Every three or four months we had to have an intervention, because the teams had grown. We started with four squads and at the end there were twelve in four locations. We learned so much during this time. One thing we underestimated totally at the beginning, is that self-organizated teams require an unbelievable amount of communication.
Lisa: So it won’t work just letting things run by themselves with self-organizing teams? You have to steer things there, too?
Eileen: To a certain extent, yes. But it’s not like the waterfall method. The trick with self-organizing teams is to ensure the people who make the decisions have access to the right information at the right time. Only they really know what information they need. So that means people have to learn where the information is and remember that. To help with this, we introduced tools like Slack. With self-organizing teams you need a completely different kind of leadership communication. The key here is the context. Without it, people can’t judge a given situation if things start to go off track, so they’re not in a position to make decisions autonomously. Classic command and control methods aren’t dynamic enough. Teams know best themselves what they need to do, assuming they know the overall big objective. With such organizations, open dialog is an absolute must – and it can really take up lots of time. The thing you need to do is keep comparing and contrasting different views and interpretations, and compare again, because you want to avoid talking at cross purposes.
With self-organizing teams you need a completely different kind of leadership communication. The key here is the context.
Lisa: How did you deal with that?
Eileen: We’d been thinking about introducing a system but in the end we decided to do it a different way. There were a number of approaches and we introduced each one by one. Sometimes we were a bit overzealous, so the organization wasn’t able to digest it; it was too much. Sometimes we didn’t do enough, so we had to follow up on things. For example we introduced these regular events called product circles and product updates. The aim of product updates was to explain the product strategy. We had this thing called a company huddle, which took place every two weeks, and teams were given the stage so they could present their current projects. Of course for a start, those kinds of meetings can be expensive for a company. The whole company is away for two or two and a half hours, but it’s worth it in the long term and it was absolutely necessary so that the agile team organization could work properly. Later we had something called tutorials, which was where employees who wanted to teach things to others could share their knowledge.
Lisa: So at the beginning you had to try out which methods would work in the long term?
Eileen: Precisely. Some techniques stuck around and with others, we noticed they didn’t work so we quickly stopped using them. It was an important lesson for us to learn as a company – which methods were a must-have for this kind of organization. But after a while we realized that we were becoming much faster and there was a phenomenal leap in productivity. Then the bug-fixing process worked this way: someone stuck a sticky note on the fridge and told people that something wasn’t working. The next day, the bug had been fixed. Nobody was really sure who’d done it, but it worked.
Lisa: So what lessons did you learn when it comes to hiring talent?
Eileen: It’s important at the beginning to be a bit stubborn and only take on really good people, people who match the culture, even if you’re really desperate to find someone. It can be quite grueling, because it takes ages to find the right people for a specific position. You have to wait at least three to six months till people outside the company have latched on that there’s this innovative, cool company out there. If you’re lucky and you can get to some really good developers through the network, it’s important to hold out for a while till they’re ready. This is especially important with software development. Developers respect each other massively for their expertise and they have high expectations of their co-workers. We had to make big adjustments to the hiring process and got the other members of the team involved really early on to improve the probability of collaboration working later on down the line. Another important aspect with the recruiting process was that we turned into an active publisher of open source software ourselves. Ultimately, that’s how the right people became aware of us.
It’s important at the beginning to be a bit stubborn and only take on really good people, people who match the culture, even if you’re really desperate to find someone.
Lisa: Eileen, thank you so much for sharing that with us – these are some groundbreaking experiences on setting up an agile team in a corporation. We’d like to share more about your fascinating work in the future, so until then, we hope it goes well!
Comments