Why SBIR might help you to increase your teams feedback culture

Photo by Hannah Busing on Unsplash

Who am I?

Hey, my name is Felix. I was born and raised in Berlin. I received a master’s degree after studying Media & Informatics at the BHT University of Applied Sciences in Berlin, Germany.

I started working at a small start up as a mobile developer for iOS and Android when I was a student. Shortly after I joined, we decided to rewrite the application using React Native. This was when I first started using React and Redux. I loved the simplicity of React & JSX and after another year as a Full Stack Developer working profoundly with React Native and React at another start up I started a full time job as a Frontend Engineer at Signavio. With this I pivoted completely towards web development, leaving the ambition of mobile development behind. I became comfortable within my new role and we grew a lot which had its climax with the acquisition by SAP last year. Today I am part of a diverse team with talents from all over the world building a crucial part of SAP Signavio’s Process Intelligence offering.

Disclaimer

Everything you will read is based on my own experience. I am not an Agile Coach and I do not claim to be an expert in this domain. What worked for me might not work for you. However I promise to be honest.

TL;DR

SBIR stands for Situation, Behaviour, Impact and Recommendation. It is a pattern/method that can be used to give feedback. It works best if it is used timely after the situation happened. Using it as a tool helps you to provide meaningful feedback which is more robust against wrong interpretation from the counterpart/feedback receiver. The pattern can be used for positive and constructive feedback. The method fits our needs perfectly as we practice agile development. We figured out that feedback giving once every few months is very hard without preparation. SBIR helped us to increase the feedback loops and value of feedback. This helped us to understand each others needs better and it relieved tensions before they became serious. SBIR also proofed to be an effective method especially for introverted characters. Even though SBIR is easy to grasp it needs some practice but it has a shallow learning curve.

Actually interested? Good! Here we go:

When I joined Signavio 3 years ago there was no major difference in mentality compared to my former employers. Signavio was clearly still driven by that start up vibe. This was what I appreciated the most. Despite the fact that Signavio just celebrated the 300 employees milestone it simply did not feel like a big company. The hierarchy was flat and respectful. I will never forget how the CEO and the CTO were joining me on my first day in the office to welcome me aboard.

However when I compare the Signavio from 3 Years ago with the SAP Signavio it is today I can say that it was a wild ride with ups and downs but with a lot of experiences and absolutely no boredom! But there was one thing that was a significant constant and that was growth. We grew a lot and this growth had implications. My daily work switched from working with a few colleagues, were communication channels were short and feedback loops were direct, to a much greater variety. This led to one imperative consequence. When the number of people you have to communicate with grows the complexity in communication is exponential.

As a developer you need time to concentrate and this is why you try to reduce the number of meetings to a bare mandatory minimum. But when multiple teams are working towards the same goal the rate of alignments, refinements and grooming sessions is inevitably higher. We conduct agile software development and follow the Scrum methodology. Thus we work in two-week sprints in which the whole team works towards a committed shared and transparently communicated goal. In order to keep focused and push towards the teams sprint goal you have to take compromises as the available time competes with the achievable throughput. The essence I want you to understand here is that the growth forced us to change the way we communicated.

In a small team we had the luxury to talk about what went good and what went bad in more detail. Hence we proactively exercised feedback giving and receiving in a more natural way. Moreover this gave us the chance to understand our impact and continuously adapt our behaviour which helped us to increase team dynamics and individual progress. With increased team size we had to focus more on overall team achievements in the retrospectives rather than talking about individual progress or problems. This led to the point where personal feedback loops went dry and everything we did was focused around the holy grail of Scrum: The sprint goal.

To enhance the feedback value our people leads came up with the idea of using SBIR. SBIR stands for Situation, Behaviour, Impact and Recommendation. It is a pattern/method that can be used to give feedback. It works best if it is used timely after the situation happened. Using it as a tool helps you to provide meaningful feedback which is more robust against wrong interpretation from the counterpart/feedback receiver. The pattern can be used for positive and constructive feedback.

I would like to go a bit into detail here as I think it is important to understand when, why and how SBIR is a good pattern to use. As I mentioned earlier I am working in a very diverse team with talents from all over the world. In fact since two years I am the only german. My colleagues are from over 10 different countries hence we are a variety of backgrounds, believes, motives, religions and values. In an environment like this you figure out quite fast that one thing you consider a banality is a topic of high interest for someone else. A joke that you think is funny might offend someone. Something you said in good will might be interpreted in a totally different way. There is a quite interesting model from Friedemann Schulz von Thun which he described as the four-ear model in 1981 which I recommend you to take a look at for a deeper dive. However the essence of what I try to make clear here is that in a diverse environment we are at a higher risk of being caught unaware by common pitfalls.

Being aware of this already helps both parties (the communicator and receiver) to be more careful when reading/hearing other peoples statements. It helps to prevent wrong interpretation upfront and calming the waves before they become a threat. In combination with none violent communication and active listening technics this is a good base for team harmony, trust and success. But in this article I would like to focus on SBIR. It is one tool of many others which worked well for me and which I added to my skillset.

I would like to give you an example of how SBIR can be used and how it differs from basic feedback you would receive or give. Let us assume the following situation. You observed that one of your colleagues (let us call him Tom) is often distracted in meetings. He is constantly typing on his laptop and it seems to you that he does not follow the topic. His behaviour distracts you and it seems to you that this prolongs the meetings unnecessarily. You ask Tom for a quick 1:1 call and confront him with your observation for example like this:

Hey Tom, you are always typing on your laptop in our meetings and I think that is not ok. You did not listen to what we talked about and because of this we had to go into overtime. Could you stop it, please?

Even though this might sound reasonable for you there are multiple potential problems.

  • Tom might feel offended by your statement as it is a general one. You are confronting him without being specific.
  • Tom might interpret this feedback as a personal attack.
  • He has no information which meeting you are talking about and even if he was typing you did not mention why you see this as a problem.
  • Most probably he would not understand your problem and internally/mentally reject your feedback.

You did not receive a lot with this kind of feedback. So how would this look using SBIR?

Hey Tom, this morning we had our refinement session about the new feature we want to make sure is prepared for the Q3 planning next week. Your input is much appreciated but unfortunately it appeared to me that you have been distracted. I have observed that you typed on your laptop a few times while not paying attention. When I asked you about the technical feasibility you came up with a potential risk which we discussed earlier on. This irritated me and gave me the feeling that you did not listen. Later on when we concluded the estimation you wanted us to repeat each and every acceptance criteria in detail to enable you to come up with a proper estimation. This not only showed me that you missed part of what we have discussed it also prolonged the meeting and we had to go into overtime to finish the estimation. I would appreciate if we could have a talk about the reasons why you need to work on your laptop while being in a meeting and if we could find a good compromise on how to avoid these situations in the future.

Let us split this feedback into parts to analyse it.

Situation

… this morning we had our refinement session about the new feature we want to make sure is prepared for the Q3 planning next week…

This enables Tom to understand which meeting you meant. It helps him to orientate himself and mentally visualise the situation. Being specific about the time and circumstances also helps Tom’s memory and it gives context to what follows.

Behaviour

…I have observed that you typed on your laptop a few times while not paying attention. When I asked you about the technical feasibility you came up with a potential risk which we discussed earlier on…

…Later on when we concluded the estimation you wanted us to repeat each and every acceptance criteria in detail to enable you to come up with a proper estimation…

In the second part it is important to make Tom aware of your observations. By describing Tom’s behaviour from your point of view. You should try to be as objective as possible here. Plainly describe what you have witnessed and how you have witnessed it. In this example we saw him typing on his laptop and when asked repeating a point which was actually already discussed. Later on we saw him asking for repetition. This does not mean that asking for repetition is a bad thing. Repeating, paraphrasing and asking questions are all valid and useful methods in active listening but in this context it is most likely a result of his behaviour. Also keep in mind that what you observed might also be wrong. Your observation comes from your point of view and might be influenced by outer factors. Here I would like to reference Friedemann Schulz von Thun’s four-ear model again.

Impact

…This irritated me and gave me the feeling that you did not listen…

…This not only showed me that you missed part of what we have discussed it also prolonged the meeting and we had to go into overtime to finish the estimation…

Once you described the observed behaviour you need to make Tom aware of the consequences/impact this behaviour had. This impact can be a fact like: we had to go into overtime because your request for repetition forced us. Or it is a personal feeling like: you irritated/hurt/offended me because it felt like you did not listen to what I was saying. Make yourself aware that this is most probably something that Tom is unaware of. He most probably did not type on his laptop on purpose to make you feel that way and this is not what we want to imply here. We simply want to make Tom aware of the impact his behaviour had to you or the group. Do not judge or jump to conclusions but honestly describe the impact it had.

Recommendation

…I would appreciate if we could have a talk about the reasons why you need to work on your laptop while being in a meeting and if we could find a good compromise on how to avoid these situations in the future…

The recommendation is not a dictation of a solution you think is best fitted. It is a wish or an offer, something that helps him and you to continue on and work with the feedback. It should be a starting point of further discussion and especially when using constructive feedback this should be an open minded, open handed offer to find a way out of possible stormy waters.

With this kind of feedback we now became very specific and also enabled Tom to understand why he receives constructive feedback from us without feeling knocked on the forehead. Tom’s reaction is of course nothing we can predict upfront but we gave him a lot more information than with the first feedback. This helps Tom to start thinking retrospectively about his behaviour.

SBIR is not the solution to all problems and it takes a lot more for a healthy team culture. We figured out that feedback giving once every few months is very hard and counter intuitive when following Scrum routines. SBIR helped us to increase the feedback loops. This helped us to understand each others needs better and it relieved tensions before they became serious. SBIR also proofed to be an effective method especially for introverted characters. Even though SBIR is easy to grasp it needs some practice but it has a shallow learning curve. I am thankful that I was introduced into this topic and I became an advocate for it. I really hope this helped you and will also increase your teams feedback culture in the future.

Thank you very much for reading. Enjoy your day!

--

--

--

From Berlin, Germany. M. Sc. in Media and Informatics. Sr. Frontend Engineer at SAP Signavio. Advocate for continuous learning.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Top 9 Must-Have Tools/ Ruby Gems for Social Networking Sites

Phox v2.0.9 — Hosting WordPress & WHMCS Theme

Playing Android with Firebase ML kit, Tensorflow Lite and ARCore 1

AWS SIGV4 for Spring Boot Applications

Splunk

Using Android HandlerThreads for Sequential Asynchronous Calls

Throttle vs Debounce

“Are you building a business or learning a stack?”

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Felix Maulwurf

Felix Maulwurf

From Berlin, Germany. M. Sc. in Media and Informatics. Sr. Frontend Engineer at SAP Signavio. Advocate for continuous learning.

More from Medium

How to Onboard 10+ new Business Analysts at the same time?

Building and re-building design teams

A guide to leading teams in hybrid and remote environments

Wireframes vs Mockups vs Prototype vs POC