Small engineering teams keep product complexity down

Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

1. 17:04

   And to me, that's very beautiful. It's half the number of parts for that. If you took Bernt from five years ago and you teleported him to today or teleported yourself back, would you make any decisions drastically differently than you have? I'd keep the team way smaller and leaner way longer. i think a lesson you learn again and again and again as you do development is that the beautiful products are the simple products and the beautiful simple products are made by very small extremely talented teams the more people you have the more complexity you will get in your product and this type of engineering just does not scale with a number of people like you can scale your manufacturing with having lots of people doing manufacturing processes testing automation all these things but like the core product design once you have multiple people you need interfaces

2. 17:51

   and once you get interfaces uh you kind of introduce artificial complexity there's a real very material advantage to how much of the system can you have in your head and understand so that you as a single person can make the decisions across the full system usually i would say like across the subsystem but ideally there are no subsystems it's just the system right now this not doable for this complex of a product um but you want to get as close to that as possible when you are trying to keep the entire idea of like this thousand part product in your head how do you kind of come up to speed as fast as possible with and have the most like accurate representation of what this thing is in your head at any given time i think it just comes down to like have you understood the fundamental principles of how the machine operates and why and if you really

3. 18:41

   understand the fundamentals then everything else is just logical like if you have a good design so then the complexity kind of goes largely goes away um and then you look at it in the end and you're like actually how do we spend this much time like this isn't that complicated and like that should really be the goal right and maybe other people look at it and they're like oh man this is complex but once you really know how it works then the magic goes away right and it's just like this pretty simple machine i think that takes a lot of time so you also need to create an environment where kind of people stick around and get that intuition and under deep understanding of the system but you can also do a lot on the tooling side which is quite important like how do you build the design tools on the electromechanical side that allows you to iterate on the product in

4. 19:28

   a way that's like verifiably correct and this is increasingly becoming more and more productive because you have so good tools especially on the coding side but that's always been a challenge like finding people who are very deep on electromechanical but are still general enough that they can kind of develop their own tools to solve the problem because most people that are very deep on the electromechanical side they're not necessarily software people but by far the most valuable people are the people who are very All across all these domains, preferably even down to like material science and everything else, right? Like how many domains have you actually mastered? And can you start to see kind of like the correlation between them? So kind of like the boundaries disappear.