[en-US] Managing feedback cycles in a tech startup

Feedback cycles are a important part of every successful tech startup environment. They are responsible for rapidly gathering information about how the things are going, how they could be and if something is not ideal for the current product. In early-stage startups feedbacks can be the key to create a great product and keep customers and a good feedback cycle is directly related to it.

What is a feedback cycle?

A feedback cycle is a repeatable scheme of consistency that is focused on gather feedback based on implementations. It can be measured using the, commonly used in interviews, STARR method (Situation, Task, Action, Result and Reflection). That cycle starts every time a new implementations is needed.

Situation

Firstly, we have a situation. It can be the need for a bug fix or the desire for a new feature and this information usually comes from the client. A situation is the first step to start aggregating information about how the problems needs to be solved - even if they are not even started to be worked on yet. The key topics here are: "why do we need this implementation?" and "which events could be the cause for that situation to be happening now?".

Task

After the situation, the next step is to write an action plan that here is most commonly called "Task", that is the actual work force to make the desired changes in the product. The definition of task is pretty simple, every planning about the effort that you make to create something new or solve an existing problem can be considered a task.

Action

Despite bein a self-explanatory one, an action, besides being the execution of the task itself is a step that should be carefully handled. An action can not be executed without a task, and a task can not be redacted without a situation. A lot of startups tries to solve inexistent problems, creating tasks without situations, or even try to execute actions skipping the task step, leading to bad product development that can be bad code, bugs, unexpected problems, subcoverage of situations and much more.

Result

The majority of the startups fails on properly organizing results. Fetching and sorting results can be meaningful to discover insights that haven't been caught by anyone yet. With the results it is possible to see points of failure, possible previously unexpected situations, hidden test cases and even product possibilities that haven't been explored yet and are an actual need to be brought to the market. Results are also very important to give meaning to the next step, the feedback.

Feedback

Feedbacks are the key to improvement, not only as a single person, but to entire teams or even entire companies. Feedbacks are the collective vision of the cycle as an entire entity, they will provide each participant's opinion on each step since the situation to the result, providing the insights previously mentioned in an easy-to-hear way, suggestions and more concise descriptions to power up the product development process. Feedbacks can provided from both the client and all the collaborators of a tech startup and should be always taken in consideration, from the trainee to the most important specialist developer.

Reflection

Reflecting about what was made in the past is the best way to avoid errors, not only the explicit ones but also the missed opportunities to make something great. Reflection sessions, even the asynchronous ones - through text -, are very important to decide the improvement points based on the past. Most of the reflection sessions will be "blank" in the beginning until the team get used to talk more comfortably about their own mistakes, strengths and how they actually work and that's normal, it's not a step that can be achieved so easily.

Luca Mezzalira similar approach

Luca Mezzalira, the author of the books Building Microfrontends and Front-End Reactive Architectures reaches a similar approach using the "PDCA" cycle: "plan, do, check, act" where he talks about a proper feedback cycle based on concrete plans that are constantly checked during the repetition of the cycle.

Diagram source: http://upload.wikimedia.org/wikipedia/commons/a/a8/PDCA_Process.png

He also explains direct relationship with various topics such as test driven development, static analysis, pair programming, dailies, pair programming and many others. You can see his complete article here.

Types of feedback

Diagram source: https://www.collidu.com/presentation-types-of-feedback

There are four types of feedback: positive, negative, correcting and motivating. As a tech manager you should avoid both negative and motivating ones. Why? - It is simple, negative feedbacks won't provide constructive information about on how the receiver can self improve, it is more like a punishment. Motivating feedbacks can appear good at the first time, but they can lock the receiver in a comfort zone causing the contrary effect to self improvement and putting the team in a risky situation.