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.

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:

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.

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.

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?

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.

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:

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.

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.

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.

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.

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.

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.

Now I’d love to hear from you what’s your experience in working with Virtual Teams?

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.

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.

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.

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.

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.

These are my six main factors of becoming a real detective:

Avoid time constraints and customer pressure. Bug-fixing costs time; very often a lot of time – which blocks you from other activities

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).

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.

Now I’d love to hear from you what’s your experience in hunting bugs in software and hardware?

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.

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:

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.

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:

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:

There are 3 main aspects a successfull Embedded Engineer needs to consider:

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.

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).

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:

Action #2: Check today where you can be more simplistic in your work.

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.

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:

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.

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.

How do you experience famous engineers? What exactly do these guys do differently? What’s your perspective? Give me your feedback.

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.