How to use feedforward for performance development

10 May

For those organisations that still have formal performance cycles, this time of year is rife with feedback conversations, performance moderation meetings and reducing an employee’s year of activity to a one word rating. Often times this is followed by a process of setting goals and defining associated key performance indicators.

Feedback focuses on the past

Many organisations are looking to change up how they manage performance. In the conversations about removing formal feedback processes and driving more frequent and meaningful conversations, there is a lot of focus on changing how feedback is provided.

But how much are we focused on what the employee sees and hears before feedback is needed? Are we equipping employees with the knowledge of what actions are available to them and when best to apply those actions?

Feedforward is one way of closing this loop.

What is feedforward?

Feedforward in management is not a new concept. In the 1990s, Marshall Goldsmith wrote a book and developed a tool around the concept of “feedforward”. He produced a questionnaire tool to analyse behavioural styles and provide suggestions for positive courses of action.

While there are correlations, the type of feedforward I’m talking about here is a little more akin to the engineering control system definition. Here, feedforward is when a system receives a signal from the external environment that triggers a certain kind of action.

It’s this engineering definition applied to design in Don Norman’s classic “The Design of Everyday Things” that prompted me to consider feedforward in the management context. Norman speaks about the concept of feedforward as the information that users receive prior to interacting with an object, site or app. Feedforward tells the user what their options are and how they can interact with an object to do these actions. Feedback then tells them whether the action was recognised by the object, and what the result of that action was. It is this feedforward-feedback cycle that helps users select and evaluate their actions.

Adapted from Don Norman’s Seven Stages of Action

Isn’t goal-setting feedforward?

I would argue feedfoward is different to goal-setting. In Norman’s model of behavioural interaction, a person starts with a goal. In order to impact their environment or utilise an object to achieve this goal, the person has to take an action. But they need a way of knowing what actions are available, and, when done, which actions will produce the desired effect on the object or environment.

Applying this to management, feedforward is the step that comes after goal-setting. Once the employee or team member has set their goals, they need some way of knowing which actions are available to them to achieve these goals.

Without feedforward, this might be a process of trial and error: taking actions and waiting for the feedback to assess whether they worked. This approach may may have a positive or negative effect on the employee’s end goal, and it may positively or negatively impact another part of the organisation’s overall system. This creates risk.

Say for instance, an employee wants to increase their sales and decides to call every client they’ve worked with in the last two years to drive sales from their network. What if the employee’s innocuous client-care call means that the company breaks the conflict of interest clause in an ongoing bid for a larger piece of work and can no longer submit a tender?

Or consider an employee who is attempting to respond to feedback to modify their working style to accommodate other team members. Without understanding what actions and behaviours are appreciated by their team members, the employee runs the risk of getting it wrong and further increasing tension or conflict in those relationships.

Feedforward can support the goal-setting process and reduce risk to both individuals and the organisation by giving the individual a way of identifying what actions are available to them, and assessing which of these actions are most likely to produce the desired result.

To use feedforward to manage people, we need to ask two questions: How do I provide feedforward? And how much feedforward must be explicit versus built into the organisational environment?

How do we provide feedforward

When it comes to the design of things, Norman states “feedforward is accomplished through appropriate use of signifiers, constraints, and mappings.” These same concepts can be applied to management. Developing a set of signifiers, constraints and mappings can guide your employee’s actions. But what are these in the management context?

Signifiers may include things such as job descriptions, project plans or development plans that specify actions that employees can take that are already linked to the achievement of a certain objective. Or they might be certain behaviours that formal or informal leaders in an organisation have that open up an opportunity for others to take a certain action. They may be domain specific rules that require a certain course of action from a professional.

Constraints may include delegations of authority or specified decision-making roles that constrain employees from taking certain types of action. For example, an employee who doesn’t have the approval authority to sign on a new supplier delivering services over a certain value is constrained from using that action as a way of reaching their goal of improving the company’s supply chain. Beyond system constraints, employees can be given constraints through clear, meaningful conversation about expectations that let employees know what is and isn’t expected of them in a particular role.

Organisations that have employee development frameworks often already have a form of mapping. They have lists of behaviours or skills that an employee can undertake in order to demonstrate their aptitude for a new role, promotion or a pay rise. If these outcomes align with the goals, employees can use these mappings to select actions that move them closer to their development goals. Mappings can fall apart though when the organisation or other external actors don’t follow through on their stated response to the mapped actions.

Implicit and explicit feedforward

To decide how much of this feedforward you as a leader must define explicitly, it’s worth considering the difference between an affordance and a signifier, which is much discussed in the world of design.

An affordance is an element of an object’s design that allows an action to be performed. For example, the hinge on a door is an affordance. In contrast, the signifier is the part of the affordance that allows a user to know they can take that action: for example, the “Push” sign on the door, or more intrinsically, the sight of the hinge on the door.

In a management context, an affordance might be something like inviting an employee to a strategy meeting. For many, this may be sufficient indication they’re expected to actively contribute. However, for others, a clearer signifier may be needed. For example, assigning an agenda item to the invitee letting them know they’re invited to speak up.

Assessing when an explicit signifier, constraint or mapping needs to be implemented comes down to who your teams are as people. Think of it as applying human-centred design to your organisational environment.

You can also consider your organisational or team risk appetite — how comfortable are you with employees using trial and error to navigate their role on the team? The less comfortable you are, the more you may want to use explicit feedforward. However, even when trial and error is accepted, it is worth considering if there are fundamental actions that can be built into your systems, processes and team structure to cut down on the error part of the equation.

Feedforward to create inclusion

Feedforward could be a powerful tool to pave the way for more inclusion, and thus more diversity in your teams. Let’s go back to our signifier example of the invite to a strategy meeting. For the bold, those who have been in that position before, and people of certain cultural or experiential backgrounds, an invitation to a meeting may be enough feedforward to let them know a contribution is expected and valued. For others, they may need a more explicit signifier to indicate they should contribute.

Providing relevant feedforward to your employees or team is one way that you can build a more diverse and inclusive team: you’re not just giving opportunity to the people who are “in the know” about what actions are available to them.

A caution

In an engineering context, a purely feedforward system may create problems because the action isn’t adjusted for what actually happens. Unless you have enough foresight to anticipate every environmental or contextual factor that is going to modify the outcome of an action, you’re probably going to want to build in feedback to adjust the actions taken based on feedforward.

The same applies in the management context. We must be careful of swinging the management pendulum in the opposite direction and relying too much on feedforward. You need a complete cycle of feedforward and feedback to set your people up for success in their work environment.

Call to action

If you’re an employee in your organisation who is currently thinking about your goals for the next financial year, look for signs of feedforward in your environment and organisational context to gain a picture of what actions are available to you. If the information isn’t there, reach out to leaders and collaborators to help you identify them.

If you’re a leader in your organisation, think about what constraints, signifiers or mapping you can provide your teams to support them to understand what actions are available to them and to choose the actions that help them and the organisation move closer to their goals.