Feedback went wrong

I reviewed a few key projects once for one of my clients, and the results were dissatisfactory. After I presented them to the CEO, he immediately gathered the meeting for project managers and sponsors. He heavily criticized them for the organization’s mishandling, deficiencies in delivery, and weak coordination – all the things I argued in the audit report. They all left the meeting depressed and without improvement plans, so the situation was quite the opposite of what I desired. And I asked the CEO what it was. “They needed feedback on their work! How will they be better without it?” – he answered. At that moment, I did not know what was wrong with this approach. After all, this was feedback, a bit harsh, but still based on solid facts, reasonable and fair, and that’s a good thing. But something was off, which made me think about this topic.

Now I am sure that we completely twisted the feedback metaphor. For now, it is a plain wrong word to describe what is really happening during reviews and post-mortems. This term came from the engineering field, and a whole body of knowledge describes it: " control theory.” We burrowed the word and dropped all the context and conditions of its usage because not every response is proper feedback.

According to the control theory, there are open-loop controls (feedforward, like an oven with a timer and heat regulator) and closed-loop controls (feedback, like climate control in your car). The difference is noticeable – in the case of baking a pie, we know for sure that for this recipe, we need to bake it at 180 degrees for 15 minutes, and in the case of a car, many things influence the ambient temperature – was a car on the hot sun or it’s freezingly cold, how many people are there, what is the compartment volume. And we need feedback to get a comfortable temperature because there are no predefined best parameters for the air conditioning. Feedforward is Jira – we set a task and then accept it. We try to describe it the way it is done. Feedback is Slack – we say what we want and control what’s happening there. If the person is not fixing the issues, we fire him.

When we say we are giving feedback, it seems superficially correct – after all, we adjust the behavior with a signal to get what we consider the desired outcome. But as I said, there is a whole theory behind this word, and appearances deceive us, and feedback often does not work as we want. What we are missing is that there is a “feedback loop” required to make feedback work properly. A feedback loop is a mechanism that speaks to the main part of a system in its language. For example, in the case of climate control, the main part is air conditioning. The feedback loop consists of a temperature sensor and microcontroller that listens to the sensor and regulates the flow and cooling. Microcontroller gives the air conditioner exact commands to execute. It knows the air conditioner job perfectly, and that’s why it is so good at its job.

The feedback loop will break if you change the sensor to another one with other coefficients, ranges, or accuracy. The microcontroller will talk nonsense, and you’ll be freezing or sweating. Every electrical design engineer knows that when you build controls for a system, you need to spend much time adjusting feedback loops to be functional. And if the system is complex enough, you are never sure it will work, and you constantly adjust for a long time until you find a sweet spot, as happens during the launch of manufacturing process control. So for complex systems, feedback loops exist in two modes – development and debugging (1) and operational (2).

In development and debugging, the developer gets feedback from feedback loops. He learns how the feedback loop functions, spending days and weeks with an oscilloscope and probes, changing the components, calculating, and experimenting until the thing does what it needs to do. Building feedback loops is not easy, and there are a few trade-offs to make – speed over stability and accuracy over transient periods, to name some.

All these aspects are totally missing in the “office version of feedback.” Very few try to build a working feedback loop instead of “giving feedback” during the yearly performance review. Almost nobody tries to make proper trade-offs and willingly chooses the speed of giving the feedback with a clear understanding that they sacrifice stability and precision at this very moment. Only some try to comprehend the nuances of the process under control and spend weeks carefully measuring its parameters and figuring out dependencies and working process controls. I once mapped KPIs and process parameters for a corporation, and they mismatched heavily. KPIs were not “control handles of the business” as they should have been. So, the feedback metaphor is broken on so many levers that it doesn’t make much sense to use anymore. It does not talk back in a language we can understand and change the behavior. The wrong kind of feedback does not feed.

But enough of the critics of the dysfunctional feedback, let’s go to the solution. What would functional feedback look like? Later on, in another company, we experimented with the project simulator approach inspired by serious games for lean systems engineering (like this one). We gathered a group of project managers and played a comprehensive computer game where you need to build production lines and earn money. But we played it very practically – you cannot just place a piece of equipment or change a price slider as you wish. You should do it as in real life – write an e-mail to the boss, hold a meeting, request a quote from the supplier, argue one product design over the other, and so on. We kept it simple, with no scrutiny, and just applied the usual logic of doing business. The trick was that the simulation scenario followed the problems and issues of the engineering projects these managers had over the last couple of years.

When they reflected on what went wrong in the simulation, they found lessons learned for their actual projects. And they never admitted something was wrong with them before the simulation. Everything was tip-top because mistakes were punished. They explained these discoveries in their own words and hopefully adopted some of them. This exercise was a feedback loop, a mechanism for translating and adapting the signals from the main process back to its inputs in a proper format. They could “eat it, not spit it.” And I find this idea challenging to apply, as we often try to force our feedback onto people. And it’s like giving the air conditioner 220 V directly when the 5 V signal does not work. Stupid when we work with electronics but somehow ordinary when it comes to people.

Discussion

It is interesting to see how the concept of functional feedback operates well in some parts of organizations while entirely off the charts in its other parts. In systems engineering, we adopt many parts of the functional feedback – we specify tasks with requirements that can be verified (so we can really give objective, test-based responses about what’s wrong with the process), we use life cycle models that allocate resources on building and using the feedback loops, we do many things that other part of the organization can adopt. Maybe we should talk more about that?

Also, we must recognize that feedback can be a two-way street. We can receive feedback (be engineers) while we give it. Remember, there are two modes in which the feedback loops exist. We must measure its efficiency and adjust if it’s not working.

And finally, feedback should be objective, with proven causal reasoning. We can no longer ignore the causal revolution if we still want to practice “data-driven decision-making.”