Controllers, sensors and systems

Earlier I’ve written about my journey towards better interpersonal feedback and how that changed my approach in several different (social) situations. In general terms I
believe that no improvement can be done without change but there is an equally important ingredient. Timely, accurate and undistorted feedback.

You broke the build!

Judgement

The concept of feedback plays a very central role in our lives, so central that there is a whole field of science called Control Theory that been dedicated to formalize the concepts around
feedback and controlling systems. In Control Theory there are basically three main components: A ‘controller’, which is used to manipulate the input to a ‘System’ in hope
of regulating the output, and finally a ‘Sensor’ that feeds back the information to the controller.

Implementing the framework

Whenever we ‘receive feedback’ or ‘give feedback’ we are essentially closing the feedback loop by ‘installing a sensor’ to our system. Back in 2007 Esther and Diana introduced a framework for feedback to me back which I see as an abstraction of the steps required to add a sensor in a social context, i.e interpersonal relationship. Since then I’ve been actively practicing giving and
getting feedback in a lot of situations and I am glad I have. The way I use this framework has however changed over the years and I will try to describe how.

Learning new stuff

Whenever I start out with something new I have this urge to ‘do it right’ which often conflicts with ‘doing it at all’. It doesn’t matter if I’m programming, practicing a new badminton serve or learning a new technique for giving feedback, I pretty much act the same way. I want a safe environment, enjoy short experiments and get encouraged by small successes.

When I started using the feedback framework I often did a couple of dry runs in my head and played out possible different scenarios to get used to the thought. Especially if my feedback was about correcting an undesired behavior. Before we continue with a few examples, lets refresh our mind and look a the four simple steps that makes up the ‘framework’:

– Find an opening
– Describe the behaviour or results
– State the impact
– Make a request

Finding the opening

In the beginning finding the ‘perfect’ opening could take me forever. I felt a need to prepare, I didn’t know much time I’d need and I procrastinated a lot because of insecurity. The procrastination phase passed once I learned a few standard opening lines like; ‘Steve, can we chat, there’s something I’ve been meaning to ask’ or ‘Wanda, do you have 5 minutes, I would like to discuss something with you’.

I found it easier to get someone’s attention if I was very precise about the time needed and if I could keep it short, i.e under 5 minutes, that helped as well. Waiting for an answer is of course also important. I also make sure the conversation is a 1-on-1 conversation as I believe feedback is something that should be delivered from one person to another, without stress nor an audience.

Describe the behaviour or results

When you are face to face and begin your ‘feedback session’ there’s usually a brief moment right at the beginning which is really tense. That brief moment was my second hurdle when improving my feedback skills. My trick is [still] to stay focused, keep the end in mind and start to deliver the feedback as soon as I can without stressing it.

When it comes to describing the behavior I try to be objective and stick to observed ‘facts’. “I noticed that you checked in over 40 files late last Friday afternoon” is a lot better than, “You broke the build again, right before you went home last Friday”. The description of other peoples behavior is easily interpreted as criticism if you’re not objective and there’s always a risk of falling into the trap of passing judgement, which  rarely results in insights nor changed behavior.

I constantly need to remind myself of this and try to stick to observations in order to avoid a very defensive conversation. I’ve also found that counting to five silently in my head after I’ve described the other persons behavior gives them a fair chance to respond when they give me their view of the course of actions.

State the impact

After I’ve listened to their part of the story I tell them how their behavior affects me. I am usually very careful about bringing other peoples opinions to the table, unless there is a very good reason to. This keeps the conversation and the feedback on a personal level. So, instead of saying “Peter and Jane thinks you’re a jerk whenever you check in code and just split without making sure all the tests run” I try a more personal view like, “It took me 3 hours before I could start on that new feature because I had to do a 3-way-merge of the code you checked in last Friday”.

Sometimes the impact is tightly connected to the behavior or the results, in that case deliver them together and pause longer afterwards.

Make a request

After the impact comes a really important part that I used to miss a lot before I knew about the framework — a suggested new behaviour or a request. I like to express myself in positive terms so I ask for something I want, rather than something I don’t want. Imagine yourself saying this “Stop committing broken, crappy code” . Now imagine a different approach like “Whenever you face a difficult merge just ask me and I’d love to try and help you” or “If you feel like storing the changes before you leave for the weekend, maybe creating a different branch and committing the code there is better?”

This is also a great time to explore other, better, options together as your request might not be the best solution and if you can find an alternative together that means:

1. You’ve understood each other
2. The new behavior contains a ‘mutual benefit’ aspect

With both one and two in place the change is almost always a breeze.

Read-Write-Delete

How I used to use the framework has changed from how I use the framework today. I have gone from a total feedback n00b towards deeper understanding and most of steps in the framework is now second nature. To self assess I usually look at myself and talk about my knowledge using a ‘Read-Write-Delete’ scale. At first I read the rules, after that I write my own rules and as I master something I start deleting rules.

In the beginning of my feedback journey I always tried to find an opening a had a prepared line, now I am more comfortable at improvising and don’t hesitate at giving feedback as soon as I am reminded about something. I however still assess whether or not it’s a good time for a feedback session.

More often than before I go into a feedback sessions without having a canned or prepared request and instead ask the person an honest question and say — I don’t know how we could improve, lets experiment. This would never have happened 4 years ago but it requires a close connection to the person I’m talking to and more trust. Removing steps from the framework in the beginning of your journey nothing I can recommend, but as you feel you’re getting better at this ‘feedback stuff’ — start to improvise.

I also remember having an extra rule at a time where I waited for at least one day before providing feedback in order to minimize passing judgement. I still use that rule, especially on the days when I’ve had a bad nights sleep.

If you find this useful or even better, if you have suggestions for improvement please contact me. The fastest way is twitter: @ellnestam another way is emailing me at ola at agical dot se.

Advertisements

About Ola Ellnestam

Agile Coach, Systems developer, Agile Practitioner and father of three.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s