Feedback could come in any form, not just the one that makes it easy to accept it – [Everyday Company Culture]

Culture is how we do stuff around here. Read more about the [Everyday Company Culture] series.

Today’s resolution. TL;DR

Feedback from the team could be returned in any form, not only formally, not only verbally, not explicitly, but by the day to day mistakes that we make. Accept all kinds of feedback. Don’t be a “douchebag”.

Today’s case

There was a requirement for everybody to write the text “Result” as a first line in the comment of his/her work when marking a task as completed. People were following the rule, but writing “reuslt”, “results”, “Done:”, “Restult”, “Release:” and many others, but were not writing “Result”.

Instead of pushing for everybody to use the right “Result” at the end we ended up with a list of possible “results” that team members could write as the first line of their result description. It turn out to be pretty funny to add new results and as of today this is the list of all the possible values, accepted by the platform. 

possible_results = ["result", 
  "results", 
  "result:", "results:", #These are added because of Ivan
  "rrrrrr", 
  "rrR", 
  "blabla result", 
  "result blabla", 
  "Special Result Line", 
  "The Result:", 
  "Release:", 
  "Release", 
  "Take this result Kiril, I hope you are having a great time",
  "Resutl", # this one is added because of Mihail
  "Restult", # this one is added because of Mihail
  "Ready:", # this one is added because of Mitaka
  "Ready", # this one is added because of Mitaka
  "Done:", # this one is added because of Aleks
  "Done", # This one is added because of Aleks
  ]

These results are accepted in any form of case – upper and lower. We have a team member that submits his results as:

TaKe ThIs ReSuLt KiRiL, i HoPe YoU aRe HaViNg A gReAt TiMe

Which is arguably, very funny.

Root cause

Feedback was not accepted. 

We as a team all accepted that we should have “Result” of the work and we should have a description what is actually the result. Generally the result is different from the goals of the task. The goal is “develop a feature”. But the result is “visit this URL to see the feature”.

We were just making mistakes when marking the result and I was pushing for the use of the correct word which is:”Result”. Nobody returned an explicit, verbal feedback – “I think we should make the result with ‘Done:’, because I don’t like writing ‘Result:'”. Nobody said this. We all understood that there should be a rule and we should follow the rule. But we were just making mistakes.

Full Story

I was trying to establish a rule in the team – when a piece of “work” is completed you must provide a short description, URL link, commit, picture/video of the new feature. This makes it extremely easy to generate release notes that we make public to the client. Only rule was

“When you submit your the description of the result the text must start with ‘Result’“.

Something like this will be enough

Result

We have implemented a new feature that shows a progress bar when downloading the assembly instruction.

Here is how it looks like

https://s3.amazonaws.com/fllcasts/content_pictures/pictures/000/003/479/4d609c2301bbe94f7a1c9825b7a2d85275c18537IS-Showing-Progress.png?1581586917

After the result is provided we use different internal tools and I could easily generate public client Release Notes for our products and platforms. Examples at: https://www.axlessoft.com/release-notes or http://fllcasts.com/release-notes

Sounds easy. Only thing you have to do is start your description with “Result”, because other values could be “time track:”, “Code Review”, etc. It took me weeks before I finally realize that we should not be strict on the value “Result”. We should be strict on the behavior that everybody should write a result, but if you happen to make a mistake and write “resTult” – that should not be a problem. We got you on the platform end, accepting different input values for result. Does not matter how you call it, as long as it is there.