‘The Power of Insourcing and Self-Determination’ with Sebastian zu Erpen, VP of Technology at tonies

Kovid Batra: Hi everyone, this is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest. He’s a believer of self-determination theory. He has 18+ years of engineering and leadership experience. He’s one of the renowned mentors on mentoring club. Currently, he’s serving as a VP of Engineering at tonies. Welcome to the show, Sebastian. Great to have you here. 

Sebastian Heide-Meyer zu Erpen: Thanks for having me. Glad to be here. 

Kovid Batra: Thank you so much for taking out this time. And today, we’re looking forward to learning a lot of things from you, whatever you have done in your career, in your personal life. And to start off, I just wanted to touch base first on the personal life so that our audience knows you more. So, there’s a quick fireside chat we have for you. I’ll be asking a few questions there. Should we go ahead? 

Sebastian Heide-Meyer zu Erpen: Sure. 

Kovid Batra: All right. Thanks a lot. So, first question. Apart from technology, I’m sure you have been a techie for so long. I am sure that’s a passion for you, but apart from that, there must be something that really excites you. Can you tell us about your hobbies, things that excite you outside of tech? 

Sebastian Heide-Meyer zu Erpen: Yes, of course. And for sure tech is one thing that, that excites me still. But it is still, I’m still into music a lot. So when I was younger, I was actually, like DJing and was also a music producer and, yeah, there was a time when I had ample spare time. Since I have kids, I have much less, so hence less DJing and music production, but I still enjoy music very much. 

Kovid Batra: Cool. So what kind of music you’re into? 

Sebastian Heide-Meyer zu Erpen: Yeah. So I was, like into Caribbean music. So, there was dance also reggae, and also mixed with more American style hip hop and other more modern musical genres later on. Yeah, so that was the basic picture that I was into.

Kovid Batra: Oh, that’s so nice. Cool, man. That’s an interesting hobby. 

All right. Moving on to the next one. Now, as you said, like, tech is one of the passions. I wouldn’t skip that thing for you. Tell us about your first experience, your first coding experience. How was it and what did you write? 

Sebastian Heide-Meyer zu Erpen: Yeah. So, and the thing is, I don’t actually remember the first thing that I wrote. But the first coding experience was a basic summer course that I did. And, I was so fascinated that later on the first thing that I can actually remember that I built was a context manager where you could enter basically a first name, last name, address and phone number and such things. And then store it on your hard disk was, all, I think it was still MS-DOS based and was only text interface based, but I liked it so much that I even started to pitch it to my family. So if they wanted to use my context manager, that actually never took off, but, I was really into that. And then what I liked about it was that I could build something, very, like, exciting and professional-looking out of nothing basically. So, that I really enjoyed it. 

Kovid Batra: Hey, I totally feel you there. How old were you by the way at that time? 

Sebastian Heide-Meyer zu Erpen: That’s hard to, to say probably around 11, 12-ish something. 

Kovid Batra: Oh, that’s, that’s pretty early actually. My first line of code was probably at around 17-18. But yeah, that’s nice. Nice to know that.

All right. Apart from your experiences, right now today you are at such a position in a company where you have to take a lot of decisions and anyone who is taking so many decisions, I’m sure has to have a source of learning so that your decisions are good. You have the right mental model in place. So, I would love to know what are you learning these days. What are your learning sources? Any specific books that you are reading? 

Sebastian Heide-Meyer zu Erpen: Yeah. So I’m actually reading less today than I’m listening. So I’m listening to audiobooks, actually a lot also for, for learning purposes. And the last audiobook that I listened for learning purposes was on systems, I forgot exactly the name, but it’s one of the standard books on systems in general, how do systems behave and scale, and such. But, I also actually occasionally listen and re-listen to learning fast and slow. Sorry, is it, how was it? 

Kovid Batra: Thinking fast and slow. 

Sebastian Heide-Meyer zu Erpen: Thinking fast and slow. Yeah. 

Kovid Batra: Yeah. 

Sebastian Heide-Meyer zu Erpen: This is one that I occasionally re-listen to because there’s always elements that I take from that I like. But I have to admit that my general learning is more now focused on other channels or ways, or I think I learn different, um, topics in different ways. Actually,  when my kids were younger, I rarely had like 30 minutes of uninterrupted time. And that was a time when YouTube, actually started to become a part of my life because YouTube videos are very short, right? And I can take in information in a very short amount of time. And, even YouTube shorts nowadays can be quite good. Yeah. So, I still do enjoy these tutorial videos. Fireship is a good channel. Primogen. So, these standard coding channels I like. I do read Gergely’s newsletter, ‘Pragmatic Engineer’.

Kovid Batra: Yeah, I know. 

Sebastian Heide-Meyer zu Erpen: Yeah. This is a really good one. So, I really enjoy it every time. ByteByteGo is a good source to basically refresh on some concepts and strategies, right? But then I still read a lot on LinkedIn and get a lot of new content. But also my teams, quite frankly, they catch new technologies and I learn from them. And, podcasts. So these are the main learning sources for me. 

Kovid Batra: Cool. Thanks. Thanks for sharing all your learning sources secrets with us. All right. With this, we move on to our main section where we will be talking about how and what did your journey look like from starting from your developing days to a leadership position.

So, before we jump into that, I just wanted to know one more thing from you. This is of course related to your career. This decision of moving into leadership and management as compared to somebody who is at the core, a very techie guy, not moving to a Principal Engineer kind of a role; was that a conscious decision or it just happened to you? 

Sebastian Heide-Meyer zu Erpen: Yeah. It’s part this and part the other. So, let me explain. So, when I joined my first company, actually, it was in the middle of an Agile transition. So it was just starting, or had just started with Scrum and had reset basically and restarted Scrum. And, in that period, they, for the first time, really placed a role called Scrum Master. So they didn’t have that before. And at the time they introduced it. And because I didn’t like my first boss, I had the urge to do something else and I saw a chance at being Scrum Master. Right. And then, yeah, I was chosen as one of the two Scrum Masters of the company. So, became that. And, was Scrum Master for a couple of teams and still a Software Engineer in one team. And at some point, they asked me, “Okay, decide for one. So, you can only be good in one. So, decide for one.” And with a tear in my eye, I made the decision to focus fully on Scrum Master because I felt I worked with three different teams. I helped solving them more of these like organizational problems, but then also like helping improve the relationships with the Product Manager. Still was, supporting on the tech side occasionally. So it felt like my scope and my impact was way bigger than pure coding. And that was basically when I made the decision and later on, then turned to Team Lead and whatnot. Yeah. 

Kovid Batra: That’s cool. I think for a lot of folks, to whom I’ve talked, who have moved into management or leadership, this is one of the most important reasons for them to switch to that. They see that impact. They see that adrenaline in them when they are managing teams and getting more people empowered to do more. So yeah, I think that’s so cool. 

All right, Seb. Tell us more about your experience at tonies, your routine. What are those important responsibilities that you hold as a VP of Engineering at the company? And what are the challenges that come along with that? So it’s a big question, actually. You can take your time to explain it. Yeah. 

Sebastian Heide-Meyer zu Erpen: All right. So I, I’ll try to make it short. So first of all, I think I need to explain what the tonies are. So tonies are the producers of a small audio player for kids. Unfortunately, I don’t have one right now with me, otherwise I would show it to you. It’s a cube basically that looks cute. And then on top there, go these little figurines that you can place on top and then it plays the audio that’s connected with this little figurine. So, we have lots of Disney characters and Paw Patrol. So, all the stuff that kids know, but you can basically use this as a creative one is what we call it. You can put your own stuff on it and it plays, what’s on the Tony. And kids can use it from the age basically of one and a half to, because it’s so easy to use and it’s more natural to them than, I don’t know, using a CD player or whatever if, if it’s existing in households anymore, right? So yeah, and that’s what we’re building. So, basically we have this tech device, right? We have the back end. We have obviously an app with which you can control it and buy additional content. We have a shop. We have other outlets, basically. And that’s within the scope of responsibilities for me. 

And quite frankly, what my job has been at tonies, but also at other companies is always like looking that everything is moving in the right direction, right? So nothing is crashing and we are really making progress on the things that we need to. And then, I’m going deep on one or two topics that are really important or really complex where I support with my expertise and my also connections, quite frankly, in my understanding, to move these topics forward, right? And I always constantly, and this is a big part of my job, try to combine the.. I have a very broad overview of what’s happening in the company. I talk to many stakeholders, but I then try to deliver this broad perspective to my teams and then get the deep perspective that they have on the specific technical topics that they own,  in order to formulate the best decisions as a connection between the broadness and the very deep expertise. So that I would say is pretty much describing my job and my day-to-day routine. 

Kovid Batra: Cool. Cool. I think what I’m interested in knowing is the challenges that you see. Of course, these are your responsibilities. And I totally understand, as a decision maker for the whole team, you have to get down to that each and every integrity. I have a lot of questions on how does this device also works. But, let me just start off with the challenges that you see in the responsibilities that you have taken up. What is the most difficult thing for you in day-to-day? 

Sebastian Heide-Meyer zu Erpen: Yeah. So, this has shifted massively over time. So when I started, the team actually was probably 60 percent external. So, because the product itself was invented by folks that have been working in agencies, and they have been used to working with agencies, so, all of the IP, all of the knowledge and quite frankly, the effort was outsourced. So external partners were doing the work, right? This is a good idea short term, but long term it’s quite expensive and also risky because, if you are, and we had situations with one of the suppliers who were suddenly saying, “Hey, we want more money. Otherwise, it’s not working out.” And then, we had very tough negotiations. So, uh, what we did is we started to insource, basically, the development massively and have flipped the script or basically actually most of the development now is done by FTEs within the company and the, the know-how and the IP is generated in turn.

Then the next thing was, um, During COVID, we had to navigate also supply chain issues. Quite frankly, there was a chip provider that told us, “Look, we can deliver, like the next nine months of the quantities that you need, but then we will not deliver meaningful quantities.” So, we had nine months to rebuild the whole hardware around a new chip, which means basically you have to rebuild the whole thing. And that was very short notice. I turned grey during that time. I learned a ton about hardware development and firmware development. And then, also tried obviously, my, like very Agile-driven, software engineering background to bring this in. So how do we do shift left quality assurance? How can we test, as small of a unit as possible to keep feedback loopers, loops as short as possible, right? And then, like have different layers of tests. And I think we learned a lot and we built a team along the project. So we started with external providers, but built an in-house team, and created the knowledge in-house. And now we have a really good, like foundation to, yeah, build basically future devices that we’re working on in the future. 

Kovid Batra: Cool. So I think this is very interesting, Seb. When you scale a small team from a few single-digit folks, the number to 60, 70, as you said, in this time, of course, that knowledge creation, that culture creation, everything becomes important. I think very important is the first step, which is hiring the right folks. So, tell me about how did you start hiring. What were your criteria there? And how did you build this strong team of developers that are working on hardware as well as software, as I see? So please go ahead. 

Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. So, the number one thing for me is obviously I scale or through my expertise only with people, right? So if I have people that are very aligned with me and I am aligned with them, then we can scale better. So what I did was at first I made with the existing, we had existing leads, I made my expectations towards them and their expectations towards me very explicit. So, had a role description, that I agreed with them and then I held them accountable and they really liked it. So then, because we were growing in size, right, I hired a bunch of new Engineering Managers. Some of them I actually knew from, from past companies. So, I had already a great trust relationship, knew how capable they were, right? Some of them were new and some really surprised me at what they basically were able to deliver and how also some of the internal folks that have been there have been growing time was really, uh, amazing. So with that in place, a great team, I could then use them to scale. And we hired a bunch of folks into the teams and invested heavily in select areas. So, as I said, right, due to the supply chain issues, we had to invest heavily in the hardware and embedded space in order to insource the IP production and also be capable of building new products ourselves.

And then, also we did a similar thing in the app. We had a, like reasonably, no, actually a mediocre app before, wanted to build a top-notch app and had to build a team from scratch, basically. Had no single mobile developer or only one, when I joined. So did that there, hired a great leader for this team, scale the team. And now, like there’s this flywheel that’s always starting to flow, right? Because the leader is like working with the team, I’m working with the leader and then they’re bringing in new expertise and new practices. And this then sets something in motion that the team understands, “Okay. If we do that, then we get faster or quality gets improved. And we get more freedom, get more time and can do more.” And that’s what’s happening, and that’s what we’re seeing, all along the teams basically. 

Kovid Batra: Cool. Perfect. Yeah. I think holding people accountable, giving them autonomy, and yes, of course, hiring from some known folks and references always works better, probably. And that really helps it because at the end of the day, it boils down to trust. And people whom you know, their working style. And once you are comfortable, it really becomes a motion where all of them are pushing towards one thing. So that’s really cool. That’s a great piece of advice. 

Seb, one thing that you just mentioned, like during COVID times, there was a supply chain issue and we know that this chip industry was really taken back at that point of time. And it’s not just tonies, probably a lot of such companies who were dependent on hardware were struggling to source chips, right? At that moment, you decided to build things in-house, right? Usually, this is a question that I ask that ‘buy versus build’, right? At that time, why didn’t you think of probably going down to a few other vendors if one vendor was moving away from commitments? Then you could have two or three in the pipeline supplying you the same thing so that if one fails, you can rely on the other, because I mean, I have had that personal experience of dealing with such hardware vendors. And this is what we did. We didn’t start building things in-house. But your story is different. Can you tell me some rationale behind taking that decision? 

Sebastian Heide-Meyer zu Erpen: Yes, of course. And also, to be fair, we did not build the hardware in-house, entirely. So it was rather done by a supplier as well, a different one with support from our in-house team. And we anyway had the plan to build a second source. So we knew we were dependent on one chip supplier, on one like development partner, right? And we wanted to have another chip supplier build a second, also, development partner in order to do this or be prepared. Unfortunately, it hit us and we weren’t prepared. So, we had to do this on the fly.

However, what I insisted on at that time is that we build the firmware in-house because what I wanted to do is to iterate as quickly as possible, as much of the feature set as possible. And, what we were doing is we made the explicit decision. The app should be the new basically digital centerpiece for, for the interaction with the product, which is natural. If you have an IoT device, then you usually control it with the app. And this is the panel for the parents. And we also wanted to get In touch with the parents more often via the app so that we have a touch point with the parents via the app and with the kids via the device, right? So, we invested heavily in making the app better and more appealing to parents and also more useful. Quite frankly, we focus on the jobs to be done by the parents and make better offerings in order to help them overcome these kind of get these jobs done basically. And by doing that, we also want it to be able to enable parents of doing certain things in the box that they couldn’t do before. And in order to have this cycle as short as possible, we wanted to have all the capabilities that we need, including the firmware capabilities in-house to really basically make all of this one month at best from idea to production. And what better way than having everything ideally in within the company, very closely connected, right? And that’s how we ultimately, came up with this setup. 

Kovid Batra: Yeah, I think I get your point here. It’s more around the concept where you want to deliver value, you know that part of your value chain, your supply chain, how much is it going to impact the overall delivery of that value to the customer. And, that’s when you decide how much control you want to have on it. And probably from there, you decide whether we should have it in-house or probably get it outsourced. That’s cool. That makes sense. Perfect. 

Sebastian Heide-Meyer zu Erpen: Quickly, if I, if I may add, like, worldly maps are a great tool to basically do exactly this analysis that you just did, right? So the more, the closer something is to the customer, the higher, the, the basically impact, that you can have on like developing pieces, closer to the customer in-house. And also the, the closer something is to your IP, meaning to an innovation. So, the more commoditized it is, the, the less like differentiation you can have as a company, but the closer it is to an innovation, the more differentiation potential there is, right? And that’s how we approach the, the whole thing as well. 

Kovid Batra: Totally, totally makes sense. I think that’s a very good way of looking at and making a decision about whether to buy versus build. Of course, it comes down to the capabilities also, how much capital you have, how much it would take in terms of resources. Of course, that also matters, but ultimately the decision-making should start from this point of how much control you want to have on value delivery there, and then probably, think backwards. Makes sense, Seb. Great piece of talk. 

Another question that I have here is that when you are owning so many things, uh, you have such a big team, everyone is autonomous, you have given them that accountability. There is a possibility that some small fuck ups happen, right? Sorry to use that word, but yeah, that happens, right? At such a scale, the impact of such failures is very big, right? And you need to have an eye on that. How do you deal with such situations? How do you make sure that you proactively control these situations? How do you do it in your company right now?

Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. The good thing actually is that with our, like product, we have resilience built-in because we always have this, this audio player that works on its own. So, if you put a figurine on top that already has been played on the player, it is stored on the player and it will just, just play it from, from the disc. So there’s not even a connection to our system. So if the box itself is functioning, no battery problem or whatever, right, then it will generally work. This already, like makes our overall offering quite resilient. However, there’s obviously still like a lot of systems that can break. We have lots of microservices that fortunately have a limited blast radius, but that can break. And this occasionally happens. So, what we do there, so we have an extensive set of metrics that we’re monitoring. And so we focus, a lot on observability in general. And we also like, use more and more business metrics so that we basically, whenever something breaks, we, we catch it, even though we might not measure the specific or see the specific technical metric go out of bounds in a range, right? But we, we see the, the business impacts, quite frankly, we also have customers that are very quick in letting us know when something is not working, so we detect it very fast usually. Yeah. And then basically the incident management process run. So, we have an incident manager that is defined. It’s usually the Engineering Manager from the area of  incident that, that sort of responsibility where the incident happens. Then we have kind of a war room chat where folks get together. Everyone who thinks who can contribute is welcome to contribute there. And it’s actually an all-hands-on-deck situation. So whoever can support should be also there. Then we do root cause analysis the normal stuff, right? So we try to find out okay, what, what is actually the root cause of what, what’s happening there. We focus on mitigation, try to basically build hypotheses, follow these hypotheses, validate them, invalidate them, come back together. And then, once the root cause hypothesis is validated, we will think about how can we mitigate it. And once it’s mitigated, then we have a post-mortem where we discuss how can we A detect this sooner and even more important, how can we prevent this from happening in the future, right? So pretty much standard, but it’s working pretty nicely. And usually, our incidents are quite short, luckily. 

Kovid Batra: No, definitely. These processes, these tools definitely help, and you just have to have that discipline in yourself. And I’m sure teams who are using these things and following these things are at a much better position as compared to those who are always firefighting. So, cool. I think that answers my questions really well. 

Apart from this, what I think is that when you’re leading a team, there is a sense of accomplishment that you feel when your teams succeed, right? It’s not just limited to yourself, it’s for the team. So, how do you define that success for your team when you feel that, yes, they are succeeding? What are those ways you measure it? How you define it, first of all. Measuring is probably second. First, how you define it for them in your company. 

Sebastian Heide-Meyer zu Erpen: Yeah, yeah. So ultimately, when defining success, I’m looking at four different dimensions of basically, yeah, measurements if you wish. So I’m looking at the outcome, which is ultimately what we’re striving for, right? So, we want to have an outcome that’s good for the customers of the company. Hence, it’s good for the company, right? And hence, it’s also good for the employees and blah, blah, blah. 

So, the next thing I’m looking at is output actually. So, this is purely the amount of work that flows through a system. Because like over the years, right, you can measure, the size in T-shirt sizes. You can do story points. You can, whatever, right? I tend to follow the idea of trying to make stuff small. And if you try to make stuff as small, so units of work as small as possible, then you can simply just measure the amount of units of work that are flowing through a system. Law of big numbers. If you have enough units of work that are flowing through, then If the amount is not going down, then it’s a good thing. So it doesn’t always have to go up, right? And you don’t need to measure 10-minute units of work, right? But as long as it’s not going down, then it’s a rather, rather a good thing.

Then there’s obviously tech health because we like producing output in order to generate outcome. We also want to do this sustainably and therefore tech health is important. So we’re looking at the amount of incidents, mean time to recovery, but that general DORA metrics would be helpful there. Tech debt should be also assessed, analyzed, ideally measured in some form, right? And then, not to forget, team health is super important so that the people, the folks in your organization are actually engaged. They feel committed to what they’re working on, uh, aligned, right? And they’re, I’m a huge fan of the self-determination theory, which pretty much says, okay, you have this relatedness, you have, the mastery. And you have the, the autonomy, which are the three main like, big dimensions, when it comes to motivation and, and this motivation that leads to, to happiness and ultimately, engagement. Yeah. 

Kovid Batra: Perfect. I think that sums up a really good vision for us to drive or tell the audience how to drive tech teams, actually. On the very first point when you talk about, like talking about the autonomy, looking at the outcome, right? You talked about outcome. In that moment, leaders, managers still align with that. But I have felt, of course, it could be a different scenario at tonies, for sure. But with developers, this comes with a difficulty, right? They just write code and they really don’t, like most of the time they don’t tend to see the value they are delivering through that code because it is, I understand it is indirectly related. You first write code, then the product works and then the product is adopted and then the features are adopted, people use it. But we definitely know that if the developers, the teams themselves are so aligned with the outcome-oriented approach while writing the code, that makes the best mix for a team, right? Do you practice that or are your developers already trained in that mindset? How it looks at tonies? And if it is not like that, how are you working towards making it work?

Sebastian Heide-Meyer zu Erpen: Yeah. So, it’s not equally distributed within the org. So for example, we have one team that is focusing on the so-called IoT platform, which is the backend that the Tony boxes, our audio players are sending their requests to, like if they request new audio or whatever, right? And those engineers are a little bit further away from the product than let’s say, those who are producing the actual box, right? Or those who are working on the app, they are consuming their product themselves, right? They’re interacting or are much closer to the customers when developing their product, right? However, that being said, I mean, we have one big advantage in that we have lots of young parents who have children who have the Tony box at home, which makes it very easy to connect to the product, right? But even if this weren’t the case and for many folks, this is also not the case, they don’t have kids and they are not so well connected, right, but we’re always trying to focus on the ultimate outcome for the customer. So, that’s when we talk about a new feature or a new, like let’s say epic, that, that we’re kicking off, right? And we are always talking in like starting from what’s the value for the customer that we are planning to generate. And we’re actually trying to do the discovery already with engineers so that they ultimately are part of selecting the solution. Exactly. Because it’s ultimately always like starting from the jobs to be done, right? You have an idea of a job to be done that’s unmet not, or undermet, in terms of offerings, right? Then you’re trying to validate this idea first. So, is the problem that you’re trying to solve actually the right problem, right? And then, you’re trying to come up with what’s the quickest solution for this job to be done. So, what’s the fastest way to build it in order to then validate it, right? And now, we’re trying to include the engineers already in this discovery phase so that then by the time we’re actually building it and rolling it out, we have the minds of engineers already on the consumer problem. So they are like, strongly connected. 

Kovid Batra: Perfect. I think this is a very good idea, actually. Involving people from the design process itself would really help them connect, looking at what those jobs are to be done by the user and then probably have that relatedness while writing the code. So, that makes sense. And of course, as you said, for tonies, it works even better because they can use their own product and see what needs to be done. So, cool. 

Great, Seb. I think it was a very good talk and thank you for sharing such in-depth things that you’re doing at tonies and giving us that insight. So, I would love to have another chat with you sometime again on another episode, maybe because I see that these 30 minutes are very less for me to know what you have in your work and in your mind. So, cool. We’ll look forward to connecting again and thanks for today. Thanks for taking out the time and sharing your thoughts with us. 

Sebastian Heide-Meyer zu Erpen: Thanks for having me. It was great. Great fun. Thank you. 

Kovid Batra: Thank you, Seb. Have a great day. See you. 

Sebastian Heide-Meyer zu Erpen: You too.