Mastering Embedded Systems

This episode is about my biggest mistake when leading a Virtual Team. It is most likely a very common mistake, but if you’re not knowing about it you might stumble into it with highest probability. Listen to this episode and get the tools to prevent your failing in working with Virtual Teams. What are Virtual Teams? Team should be obvious. In german it is capable to disarrange the starting letters T,E,A,M into Toll, Ein Anderer Machts. That means: “Great, somebody else is doing the job.” That’s only a joke of course. You know there are some opportunities to hide within a team. But the use of a team should be obvious. A Virtual Team now means a group of persons working together only in a virtual way. Regular teams usually have a quite close connection. Sitting together, talking directly to each other, seeing each other and having the direct grasp on each other. All that is not available in Virtual Team‘ing. Virtual Team members are off-sited. Sometimes even part of other organizations. And Virtual Team members regularly work together by using online media like email, chat, video-connection, phone calls, etc. Their main challenges of working together are: Time zones Language barriers Cultural differences Behaving differences Each of these challenges needs different treatment and special attention when working in Virtual Teams and especially when leading Virtual Teams. My biggest (rookie) mistake as Virtual Team Leader was that I did not take into account that the guys are different. Not only a difference in language or look, but they are different in culture, beliefs, values and habits. Of course I have known that there are differences, but I have not acted like that. The map is not the territory My main failure was that I simply assumed the guys are like me – like a german. A german engineer. Someone thinking that there is only one truth. Someone very often thinking he knows the exact truth. And if you know the only truth, everything else could be only not the truth and must be therefore adapted. That’s a very rational, very ego-centric, but very common understanding of the world in Germany. That’s one of our essentials. We’re struggling and discussing about the truth, but when we have it, then it’s invariable – because it’s the truth. Oh man, I was that wrong. Let’s make an example: at one time I have overtaken a virtual team with members in different European countries. I run into a problem with the guys as we were still in the forming phase of the team. I wanted the guys to do something. I have explained it. I have enabled them to do it. I have checked whether they have understood what should be done. According to my understanding I have done everything that within my regular context of Germans the things would have been done appropriately. I fully relied on the assumption that if there would have been contradictions or different opinions that the guys would have told me. But there was nothing. No response. No question. Only the result. And that was far away from everything I would have expected. Do not misunderstand me, the guys have done a lot of work (and that’s the sad point because I was responsible for the waste of time and effort) and they presented proudly their results. But it was not even close to what I have expected. I was that astonished and frustrated. But that was pure luck. Because it gave me the attention I needed. It was obvious, if the results are that far away from the expected results, something must be wrong in general. I talked with each of the members separately. I asked them to understand what exactly they have understood what should be done. The answers were surprising. They were aware that they haven’t understood in detail what I wanted to be done. What? Why do they have not told me? Why do they have not interrupted me? My thoughts at that point (as a German) – if I have something significant for the absolute truth which is not covered in the truth told me, then I add that, because otherwise it could not be the truth. Understandable? Thus I asked the guys and I got as a response that it is not acceptable in their understanding to provide the leader such comments! Bamm. That was heavy stuff! Not acceptable to add sth to the truth? A big swallow on my side. I digged deeper and in fact I got the responses that especially Germans have a very high reputation in their countries and nobody wanted to interrupt or disturb them. That was really crazy. I asked them whether they could imagine that I’m wrong with my actions – and pushed them in real internal conflicts. They could not imagine that. And I could not imagine that they act in that way. Amazing. It looks like we have stumbled over a conflict in our maps of the world. Our internal representation how our world and our reality is working. What does that mean? There is a NLP presupposition: The map is not the territory Our internal map of the world and our reality is built by: our 5 senses, modified by neurological processes or filters, forming values, beliefs, rules and capabilities and it impacted and biased by deletions distortions generalization Generalization is the basis for the formation of our beliefs. What we believe about the world is how we interact within it. Most often it is our beliefs that limit us. We have beliefs about spirituality, the world, our capabilities and our environment, right and wrong, what is just and unjust, and whether or not we can change. Values are the things we invest our time, money and effort in trying to attain. Examples: Fun, freedom, money, love, honesty, integrity. They are what is important to us. And we have very definite criteria or rule structures about how we go about attaining them. Everybodies internal map of the world is purely individual and unique. That also means the realities are different! And that means the truth is different! Or better: everybody has his own truth. A very “bad” conclusion from my german perspective Especially differences in very general aspects of reality are the source of problems, like education, family, culture, religion, etc. How to avoid my rookie mistake as Virtual Team Leader? Visit your guys That’s a very essential point. Become familiar with each other. On a very personal level. You guys will work together for hours every day. You should know the person on the other end of the email-line. A gathering is very worthful for working in Virtual Teams. Jan Lorig’s study about Success Factors for Virtual Project Teams (released in 2014) mentions “Face-to-Face kickoff” meeting as number two factor within a range of 15 different success factors. All contributers in this study remarked the importancy of initial familiarity for the success of Virtual Teams. For the leader this means, insist on having such kick-off-meetings and show the benefits in avoiding wasted effort due to misunderstandings and mistrust. Moreover for the team-leader this means to visit the different sites with Virtual Team members often. I have done that in a range of 4-6 months. I remarked a loose of touch with all the members after 2-3 months. After my next visit the tight personal connection stayed in place for an additional 2-3 month period. But it needs permanent refreshal. Keep that in mind if you want to succeed with your Virtual Team. Establish an atmosphere of trust and open mindness. Consider you’re running a team which members do not see each others on a daily base. There is no “good morning” or a coffee-/tea-break in between. Only regular phone calls and meetings. But both are driven by intention or pressure of outstanding work duties. There is regularly no small-talk or personal calls. Establish a direct chat-possibility. The members of your team should be able to come into touch with you everytime. Treat them with very high priority. Or give them a call every now and then simply to stay in touch. With no particular reason. Same as you would do if they would stay on your site. Ask your guys what exactly they expect from you in your co-workership. This can be very careful as it means they have to phrase the potentially clouded or unclear excpecations into something more concrete. Note it down and keep it in mind. It’s such worthful to understand their actioning. Get familiar with your team-mates’ culture, beliefs and values Try to gather what are the main aspects of their culture. What are their regular beliefs and values. That’s of course no topic for the first meeting. But keep in mind and if you have the opportunity, then ask. Be very open minded. Listen. Do not judge. Simply collect. Ask the members of your Virtual Team how they feel in their role. Listen carefully if you here generalizations or deletions in their sentences. That’s exactly the point where beliefs start and the underlying map is shining through. Try to evaluate when your own map is overtaking and you’re assuming you have understood something. Very often you hear something and you generalize and think you have understood. But it perhaps has only triggered one aspect in your map and your created the rest by yourself. Build up your model of their reality It makes sense to minimise the need for assumptions by finding out what is actually in each other’s map. The process of finding out is called modelling. Do it this way: Let tasks or duties be repeated by the team-members with their own words. Let them tell you what exactly they think are the main goals of this task and what this goals mean to them. That’s of course some special activity for the beginning of your coworking and it can be reduced or dropped afterwards. I meanwhile use exactly my own failure as the reason to request this action from the team-members. And all of them have understood this approach and appreciated this thinking ahead. Use the other persons word, but do not assume that you’re meaning the word in the same way as they do. Clarify the meaning of words! Listen very carefully what the guys tell you and ask questions if you do not understand. You can detect misalignments in speech by a simple pattern: everything said you cannot pack into a pushcart is a substantivation and must be evaluated. For example: “This task needs my full attention.” You cannot put attention into a pushcart, don’t you. Therefore ask what exactly the person understands with attention. Curiousity and tolerance Both aspects are needed for sure when leading Virtual Teams. Become the nosiest person in the world belonging the way your virtual team members are thinking and acting. No control, but ask them a lot. And give yourself and your team-mates room for tolerance. Within Virtual Teams you must be much more tolerant than in local teams where you meet members face-to-face. Accept misunderstandings as a regular part of your Virtual Team‘ing and don’t get frustrated. Keep going and avoid the same mistake the next time. What about you? Now I’d love to hear from you what’s your experience in working with Virtual Teams? What failures in Virtual Team working have you observed? What are your preferred approaches for handling these inter cultural gaps? What kind of challenges do you see in Virtual Team’ing? Do you have a habit or problem that I didn’t list here? Or do you wanna agree or disagree with me about these actions? I’d love to hear from you. Please comment on the show-notes at the embeddedsuccess.com/episode03. And let me know your experience, your thinking and what you’ve done in similar situations. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post My biggest (rookie) mistake as Virtual Team Leader – MES003 appeared first on Embedded Success.

In this episode we will discuss why bug-hunters are scarce resources. And how to improve your skills to become a more successful bug-hunter, in the Embedded World. I will give you my 7 main bullets to improve your bug-hunting skills to a new level. Why do we need bug-hunters? A successful hunter of hardware- and software-bugs is no profession or even education. Most of all educations are either ignoring the fact of bugs or they are simply assuming that you or others do not make errors. The only thing you might receive or you are forced to experience is the training on the job. The knowledge about bug-hunting is mainly empirical. That means you need a lot of intention and also experience to become better. Many of us have undergo this painful and stony way. This episode is about presenting you my experiences which I have collected over the years. I will tell you some guts to become a solid bug-hunter much more faster and more reliably. Moreover following these tracks might even let you think more consciously about preventing bugs at all. What’s missing for bug-hunters? Guidelines and the distribution of knowledge. There is no regular exchange of experiences and occurrences of failures. Most engineers only learn their from their own mistakes. However there are ten thousands of others who might share their experiences, too. Even the more experienced engineers will take the chance to improve their own bug-hunting approaches. If they would need others! But there is no distribution. There is no sharing in a bigger audience. I was confronted with a lot of bugs and problems within my professional life. Perhaps you’ve experienced the same. Let’s use this episode to share our experiences and participate from each other to become more effective and more efficient engineers. Let’s take this opportunity and collect some bug-hunting approaches and learn from each other. How to improve your bug-hunting skills Use my list of seven bullet points to become a successful bug-hunter. These details are the result of more than two decades of bug-hunting and bug-prevention. Two different general approaches to look out for bugs The destructive approach by instrumenting your code or drilling down the functions The Non destructive approach by comparing or jumping back in revision history and getting the big picture about the constraints and real requirements of the system The detective’s mindset – feel the excitement of hunting These are my six main factors of becoming a real detective: Collect facts Collect suspects Do not trust witnesses Create your own track If nothing runs, switch to Sherlock Holmes mode Play the devil’s advocate or Good Cop – Bad Cop game Change your mindset and assume the system behaves correctly What’s wrong in your thinking if the system is correct? How do the code-path looks like if the observed situation is assumed as correct? Where is the thinking loop which prevents you from achieving the desired outcome? Use internal resources and do not fight alone. Use your internal skill matrix. Expand your personal who’s who. Do not underestimate the time for failure maintenance Avoid time constraints and customer pressure. Bug-fixing costs time; very often a lot of time – which blocks you from other activities Narrate your bugs and findings Let others participate. Very often bugs are tried to be hidden. Especially then they are assumed as embarrassing or rookie-bugs. But do not be shy. Make the first step and announce your findings officially having the bigger success of the whole company in mind. See the Japanese approach of Best Practice Sharing, the Yokoten-kai (alternatively here). There is no multitasking in human brains Very often overseen, very often thwarted. Newest research have unveiled that every context switch needs at best 30 minutes to come back to the original position in your thinking. This is a call to all leading persons. Do not burn up your engineers’ brain-power by pushing them from one topic to another. Let them concentrate. On one issue. At one time. For at least 4-8 hours. Request feedback Now I’d love to hear from you what’s your experience in hunting bugs in software and hardware? How do you do bug-hunting? What are your preferred approaches for bug-hunting? What kind of challenges do you observe in being a bug-hunter? Do you have a habit or usage that I didn’t list here? Or do you wanna agree or disagree with me about these approaches? I’d love to hear from you. Please comment on the show-notes at the embeddedsuccess.com/episode02. And let me know your experience, your thinking and what you’re using and how you’re using it. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post In a world of bugs – how to become a successful bug-hunter? – MES002 appeared first on Embedded Success.

Yes, I know. This title is provocative. It’s challenging. But let’s have a closer look. For simplicity let’s take the approach and equal famous with becoming a recognized expert. There are two ways to fulfill this request: You become an expert by declaration You know these situations, somebody arrives at your desk and addresses you as the expert for whatsoever. If that happens several times and constantly you can admit that there must be something that others consider you as an expert. You become an expert with 10.000 hours of experience. That’s the well known rule of thumb. After a significant amount of time working in a particular environment it can be assumed, that you have become an expert But are both rules true? And are only these rules of observation available? I assume that as many times the truth might lay somewhere in between. In my opinion becoming a famous engineer depends on your individuality. Your personal intention and motivation to do this job or profession. Mainly driven by the question, how your special approach looks like when facing different tasks and challenges. Over the years I have observed several ways how individuals become famous – but not all of them were successfull. I have extracted five basics within Embedded Systems to make your approach to become a famous engineer successfull. Getting closer To come closer to these basics, let’s first look on the entry statement from a slightly different angle. Let’s change it into the question: “Why does it seem that complicated to achieve the right knowledge to become a famous Embedded Engineer?“. There are several reasons, but mainly: Embedded Systems are different from regular computer systems. Let’s face one definition of Embedded Systems: Embedded systems are limited stand alone computing devices usually dedicated to perform limited computing functions reliably, securely and with minimum upkeep costs. Embedded Systems are a combination of hardware and software. This increases the complexity of the system impacting the behaviour of the system over the time, i.e. race-conditions, etc. And Embedded Systems arevery often quite hard to understand The most challenging problem however is, that there is no dedicated education to become an Embedded Engineer. “You learn something, but you do not know whether it is the right thing.” What’s regularly learned? Regularly during computer or IT studies it is emphasized to understand abstraction and object oriented approaches. On the agenda are a lot of scientific details, combined with abstracts about  creation and design, processes and methods. However, is that really the knowledge which is needed for a successfull Embedded Engineer? This leads us to the question: What type of engineer is needed? There are 3 main aspects a successfull Embedded Engineer needs to consider: Thinking in small systems the systems you are working with as Embedded Systems are regularly smalls systems in a matter of hardware resources and therefore also software capabilities. How well do this system match the required functions. And if it matches how well can it be maintained? Thinking in limitations working Embedded Systems is a never ending story of limitations. What’s limited within these? Processing capacity Storage capacity Energy efficiency Resposiveness Reliability Integrity Handling Cross-functional thinking An Embedded System is a combination of hardware and software. The designers, implementers, testers and their leaders needs to be able to talk to each others across departments or industries. The Hardie (You know that? Don’t you? The hardware-engineers are hardies) should be able to discuss and understand the Softie and vice versa. Systems like the control of a big excenter-press (800 to of press weight), need for electro-technicians, system-Engineers, mechanics and software-specialists working close together. And they all need to talk together, understand each other and finally agree with each other. 5 smart principles to become a famous Embedded Engineer Now the pieces come together. Here are my five smart principles you become a first class Embedded Engineer. I will give you a short action for every principle. Give it a try and test your own level. Limits, limits, limits Embedded Engineering means dealing with limits. Every Embedded System has tons of limitations. You should know them all. At least the ones impacting you. Whether this is the available RAM, the temperature-range, the CPU-power, the other applications, the Operating System, the network bandwidth, or whatsoever. You should know the overall architecture to understand the limitation of your system. If you’re only looking into your Eclipse-based development environment or dealing with your Hardware-simulator you will never understand the big picture. It should be one of your major desires to understand the system in general. This will simplify a lot of your things. Don’t hesitate to read architecture documents. Ask the architects if you do not understand. Start asking your senior engineers that they provide you knowledge and information. Don’t be shy. Action #1: Dig out the limiting details about the system you’re currently dealing with. Try to understand the implications of these limitations. And point out how these implications change the system itself and the way you have to deal with it. (I’m sorry that I have forgotten this action in the podcast-episode). KISS-principle Keep-it-simple-stupid means to make things as simple as possible. Very often problems are overcomplicated by the engineers. But the break-down is not done to a sufficient level but stopped before leaving too big chunks. Therefore some small guideline to become as small and simple as possible: Task breakdown into sub task; 4-12 hours each Problem breakdown; each problem one or very few classes/functions Small methods – no more than 30-40 lines; only one use-case solved not many at once Solve before coding not vice versa If you’re smart enough to break down on-the-fly then do it. But refactor on all means over and over again. Do not be afraid to throw away code Following these advices leads to minimal code For all other scenarios: keep it as simple as possible. That’s the hardest pattern – because it needs time! Action #2: Check today where you can be more simplistic in your work. Thinking out of the box Change your perspective. You’re regularly only familiar with your perspective on your piece of work. But later on, when the system is in operation you will not be confronted with this view any longer. Instead you get the tester’s view or finally the customer’s view. Therefore make yourself familiar with other perspective on your system. Be aware that your will get a different perspective on the system when it is used in operation. You’re not longer receiving your algorithm based view. Instead you get the view spend by outsiders. And the bad news is that it will be your task to prepare yourself for this difference. You will be asked for the reasons of the observed problems. Even without having your logs available.. And all starts the way how you will comment and instrument your code. Imagine the code running for years. You will have forgotten the internal way of working of your code. Thus you will not understand your own logging. It only shows the algorithm working – and that’s what you do not know any longer. Change that! Change the way you instrument your code. Change your perspective on your code. Get into the perspective of outsiders, of testers, of customers. For me this is an essential principle because if widens your view on your system. It makes things easier to understand if you’re not limited by your own (small) angle of view. Action #3: For the next week whenever your start implementing code take into account that you will see your code first again in 5 years. Adapt your comments and outputs the way you understand them initially even you have not handled this system for 5 years. Test on real systems Very often Embedded Systems are tested using simulators. But, I have never seen a simulator for Embedded Sytems which is a 100% equivalent of the real system. Even the NASA will not rely on simulators but create an exact duplicate of the system in use. Simulators fail for several reasons: not fully implemented features of the real systems, distracted timing and function conditions, irregular behaviour in operation, or simply some implementation errors. All the time you might follow the simulator’s results might weigh you wrong safety! The time saved by parallel development of hardware and software has regularly to be spend back to harmonize the non matching hardware and software systems. I have seen differences in simulator and real hardware that big, that they have had to reimplement major parts of the software. Or there are new versions of hardware available which are no longer matching the existing simulators. You see – the alleged benefit will be thwarted into a major drawback. Action #4: If you have not tested on the real system – prepare for tomorrow to get a first run. Get the results and fix your glitches and problems. Looking over the fence Famous engineers are opening their eyes, their ears and sometimes their mouth. They are aware of the main trends in the industry. They do not get stuck in their area for ages. They are in touch with the on-going stuff. They are in constant touch with new streams in technology like Internet-of-Things or general problems like security and integrity. Make yourself a listener and a viewer. What’s happening in your industry? Diving deeply into details is fine, but do not get lost in your very deep drilling hole. You might reach back and it’s dark aside because everybody has gone somewhere meanwhile. Be attentive. Action #5: Discuss with your colleagues and friends about the main trends in the Embedded Systems and IT overall. Finally… How to become a famous engineer? How do you experience famous engineers? What exactly do these guys do differently? What’s your perspective? Give me your feedback. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Why you never become a famous engineer – and 5 smart principles bringing you back on track – MES001 appeared first on Embedded Success.

This is the first episode of the Mastering Embedded Systems podcast provided by Embedded Success. A podcast for newcomers, experts, leaders & managers working in the Embedded Systems realm. I am Georg Lohrer and I will be your host for this podcast. In this episode, you’ll hear more about: Only very short story about myself – only very basics, promised. The main four problems I have identified when doing projects within the Embedded Systems realm. My motivation to start this podcast and why I think you should listen. The bullet topics I want to handle briefly and intensively in this podcast. This podcast’s structure, the schedule, upcoming contents and further details. Thank You For Listening Out of all the podcasts available in the Internet you tuned into mine, and I’m grateful for that. If you enjoyed the episode, please share it by using the social media buttons you see at the bottom of this note. Also, I would be very happy if you would consider taking the minute it takes to leave an honest review or rating for the podcast on iTunes or Stitcher. They’re extremely helpful when it comes to the ranking of the podcast. For sure I read every single one of them personally! Or, if you prefer a more direct contact, don't hesitate and drop me a note at feedback@embeddedsuccess.com The post Out of practice into practice – MES000 appeared first on Embedded Success.