Gimme Gimme Gimme Feedback After Midnight

I'm a Control and Automation engineer. At first I thought "oh so it's just Mechanical, Computer and Electric Engineering mashed together? Since I don't know what I want, let me get all three then".

Boy was I wrong.

There's one key thing that Control and Automation (and sometimes called Mechatronic) engineers study that the other majors don't.

Feedback.

Feedback is the subject of study inside Control Theory. In Control theory, we study, well, how to control things. Let me give you an example.

There's a kid learning to walk in a straight line.

If the kid is blindfolded, they can walk for a bit in a straight line but will soon start deviating from it. And the kid won't know it.

Now take the same kid, and tell him to continue walking in a straight line, but every 2 steps, he is allowed to look without the blindfold on.

You will get a much better result.

The difference between the two scenarios is that one lacks feedback and another has it(although not real-time).

Feedback comes from two words, "feed" and "back". If we imagine the flow of information in the system as a social media feed, in the first scenario the kid sees no new information. In the second scenario, the kid sees one piece of information every 2 steps(as if he opens his eyes every once in a while and sees a feed on social media).

That's the feed side. The "back" side is because the kid only sees the information he himself created. He knows what his previous actions resulted in every 2 steps.

That's how feedback is treated in Control Theory.

And it's how in Control Theory we say a system is closed loop or open loop. If there is no feedback, it's open loop, and if there is, the loop is closed(closed loop).

Pretty simple right? Here's an image of such a system.

Up until now we only talked about the Input: steps the kid takes, Output: how outside of the centered line he is, Process: the kid walking, and Feedback: the kid seeing how outside of the centered line he is.

Feedback and the Process are very similar, feedback is exactly the process at the time it was observed.

Now we talk about Controllers.

Controllers are responsible for correcting any errors between the Output and the Process, by observing the process with Feedback.

In our example, the controller is whatever goes on in the kid's brain that makes him go "Oh I need to go more to the right the next few steps to get closer to the center line".

Now that we know these basic concepts, let's get a bit more advanced.

When we talk about feedback in control theory, we must understand that it's a very SPECIFIC kind of feedback. It's not the "Oh my boss gave me feedback". It is a very quantified feedback "Power voltage on the transformer is 10V and it should've been 12V" or even "Weight on the scale is 10 kg over the limit".

And we also need to understand the context of this feedback. Not only it is very specific and quantified, it assumes that the "optimal output" is known.

Let's think about this last thing. When in your day-to-day life you knew exactly what the "best result" would look like?

But these limitations help us engineers run our calculations and discover interesting things like:

• How frequent can the feedback be until it starts damaging the system?
• What kind of feedback is best for each system?
• When is feedback useless?

And now why am I telling you all this?

It's because some of these learnings can be used in a more complex environment. Surely you would hate to get direct feedback on your work 7 out of the 8 hours of your workday.

That points us in the direction that there is an element of frequency in human feedback as well.

And you probably like some kinds of feedback more than others. Just as you see you have more actionable advice from some type of feedback than others.

And then we get to the last question, when is feedback useless?

Let's go one by one.

How frequent should feedback be?

In control systems, you'd think feedback is the best thing ever right? The more the merrier!

Hold your horses. We have discovered that if your system has a very high frequency of feedback, it might actually perform worse.

Think of it like this, if the system receives feedback in a higher frequency than it can self-correct for, this extra feedback can actually tax the system and make it perform slower.

At best this system will perform at its maximum capacity for reading this feedback and running its calculations, at worst it will be overclocked and overworked and might perform slower.

This is just like you working and having so much feedback that you don't know what to prioritize.

Now there's another element to this. Noise.

Sometimes by raising the frequency of feedback, we get a lot of feedback on things we didn't want.

Imagine the kid opening his eyes and seeing every nanometer he moves just by standing still and acting on it instead of the steps.

He would start self-correcting so much that it might even make it worse for him to get to the center line.

Noise is all around us, and in engineering what we do to stop taking action on random information is to either limit the frequency of feedback or to make our system much more robust against "small random things happening".

In a day job situation that would mean figuring out what's the best one can do with the feedback it's given without feeling overwhelmed.

And "making the system more robust" would mean making oneself more "thick-skinned" against feedback, and checking which feedback is actually useful and which isn't.

What is the Best kind of feedback?

In engineering, the best kind of feedback is SPECIFIC, as much accurate as possible, and captured as close to real-time as possible as well.

We don't want feedback that is vague, after all, we're meant to take direct action from it.

If the kid opened his eyes and the feedback he got wasn't how far away from the centered line he was, it would've been useless to him.

What he needs is direct instruction.

But real life is far more complicated than that, we often have to deal with emotions and people's relationships with each other so that they perform up to our expectations.

How do we proceed then? Well, the more objective the feedback, the better someone can act on it, the less objective, the harder it will be.

So think about this when giving feedback, if it's along the lines of "Oh I liked how you conducted this meeting when you asked this question and this one" it's more useful than "I like how you communicate".

Specifics. "You did this but you shouldn't have" is far better than "You're underperforming".

When is Feedback Useless?

We've touched on this bit before, now let's get to the deeds.

As a general rule, if your feedback is not related to a specific output you want to improve, it is useless.

It is trying to tell the kid that he is breathing too much while all we care about is going in a straight line.

In human relationships, it looks like throwing too much feedback that doesn't have anything to do with the situation.

Another type of useless feedback is completely generic feedback "I like how you talk in meetings" is useless, while "I like how you start the meeting with X question for the client" is good feedback.

Anyway, let me know what you think about this, was this post useful to you? Let me know in the comments below.

😗 Enjoy my writing?

If you read more than 2 of my posts and loved them, we have an honor code, meaning I give you value and you hit that subscribe button.

Forward to a friend and let them know where they can subscribe (hint: it’s here).

Join an Exclusive Tech Friendly Community! Connect with like-minded people who are interested in tech, design, startups, and growing online — apply here.