Tips on providing constructive feedback

Feedback has become a versatile and often used word in the work culture. It covers many situations, be it casual discussions among colleagues or yearly performance reviews with the boss. While some people have had good experiences with it, others dread it. But do we actually know how to give proper feedback? How much thought do we put into it?

Business rationale

It is no longer an industry secret that feedback can largely contribute to companies‘ performance, growth and culture. Proper feedback not only engages people but it also plays a vital role in improving processes, communication within teams and overall productivity. While there are many tips and tricks out there, we’ll look at a few pointers that often get overlooked. Hopefully, these will inspire better feedback sessions in the future.

Make it a regular affair

Feedback should be given freely and regularly instead of letting it pile up until the yearly review or saving it for the first chance at lashing out against a colleague. There is no benefit in keeping things that need to be said quiet, positives and negatives. All that improvement and learning potential goes to waste. Frequent feedback will also ease the tension in the formal feedback rounds as many things were discussed before and there is a lower surprise factor.

Be as specific as possible

Specific feedback leaves little room for ambiguity and interpretation. Feedback should contain facts, concrete examples and first hand knowledge as opposed to generlized statements based on knowledge from other people’s views. A positive comment like „your team did a good job“ is nice to hear, but lacks content. It doesn’t tell the person receiving it what exactly went well and can be continued in future projects or what should be changed. Instead, statements like „Person A did task X well“ or „Person B showed great problem solving skills when doing X“ give more insights. Feedback should not be about getting personal, pointing fingers or exaggerating, as this will only lead to the person receiving it getting defensive or fearful. This, in turn, creates a toxic environment to discuss any performance, and deceives the entire purpose of feedback.

Focus on just a couple of topics

Limiting a feedback session to just a few points and sticking to one point at a time is more likely to drive home the intended message without the risk to overwhelm the person. A long list of, albeit constructure, criticism, or jumping constantly between topics, no matter how good the arguments brought forward are, could make the person receiving the feedback feel attacked and become closed off.

Provide suggestions/ideas/solutions

What good does positive criticism do to a person who is not aware of said behavior or of ways to change it? Following the above steps when giving feedback is a great start. What makes it better is looking at solutions with the person and discussing together concrete suggestions going forward. There are many models to go by that can help the person stay on track and achieve his/her goal and lower the chances oft he same recurring feedback. The SMART model is a classic one and stands for setting goals that are Specific, Measurable, Attainable, Relevant, and Time-bound. This mnemonic serves as a guideline to the person giving the feedback to stay specific in his/her topics and the person receiving it to set goals that are achievable and clear. It is a win-win situation.

It’s a two way street

To empower someone to change any small or large behavior it is important to listen to him/her, establish honest and open communication that relies on mutual respect and trust. Perhaps there is a good reason why the person reacted in a certain way in that particular situation. One-way topdown feedback could make the person become closed off and even hostile, which will have a negative impact on future feedback sessions and hinder communication.

In the agile world the motto „build, measure, learn“ dictates the pace and progress of development. This concept relies on feedback and is what leads to better products and applications. Why not take inspiration from it, and engage in constructive and effective interpersonal feedback? The worst that can happen is that we experience more harmoniousrelationships in the workplace, higher productivity, and continuous learning. There is definitely worse than that.

13 Aug 2018

Insights English

by Ingrid

Acrontum Team Spotlight #2: Ingrid

We are very happy to introduce Ingrid, our versatile team member with a multicultural background (Romanian / Italian / German) and years of living abroad experience.

  • First Name: Ingrid
  • Country of Origin: Romania 
  • What I do: I manage projects from SMEs that aim to establish a or grow their online presence through landingpages, Websites, applications etc. For these clients I also manage the internal support channel 
  • What I like about acrontum: that it is very diverse in colour, languages, and thoughts. I like the flexibility of the working hours, the weekly fresh fruit, the fact that we are growing and connecting more people and interesting projects, the dynamic and young at heart colleagues.
  • Hobbies: sports (tennis and yoga), gardening, experimenting with vegan recipes, hiking, learning about innovation in education.

26 Jun 2018

Team English

by Katty

Documentation Driven Development - Part 1

At acrontum we made the decision after plenty of careful consideration to adopt a new and growing trend, “documentation driven development” via “swagger” and now the newly updated specification, “OpenAPI 3”.

Documentation driven development (DDD) is not something new (some of its earliest concepts date back to 2011), but up until recently it never had an officially accepted name, nor an industry standard for the world to agree upon. It is the process of describing & designing API's and what one expects as a request and should respond with. This enables a front-end team to easily use an API within their apps and mock the response without an actual API to talk to.

Documentation driven development at acrontum is very simple and essentially boils down to a two high level and basic principles:

  • Design the API first, then build it
    • The API design must adhere to the OpenAPI Specification (formerly known as Swagger)
    • The yaml file can be broken up with swagger-chunk
    • The finished result of the API design should be a Yaml or JSON file
    • The actual API routes should be built on what is documented in the design
    • The client, eg the browser, should communicate with the API via a generated file, built from a tool such as swagger-code-gen
  • An endpoint not documented should not exist
    • A JavaScript front-end engineer using a generated DDD API access file should not look outside of this file to access the API
    • As all routes must be documented, any other routes can be seen as not required &/or dangerous

Adhering to DDD has simultaneously increased development speed whilst solving a growing issue regarding how the front-end and back-end teams both build and communicate. Further more this is not limited to company cross-team dynamics but also expandable to cross-company communications. 

Case Study

A recent project for BMW saw acrontum developing multiple API’s adhering to the aforementioned DDD principles where the main API was consumed by an Angular5 application, also built by acrontum.

Before work commenced, the API’s were designed using the Swagger2.0 spec. Upon the agreed design, both the front-end and back-end team could commence work simultaneously. The front-end team knew how the API would look when complete and could simulate the API using a mock server outputting example content. Conversely the back-end team could pick and choose which routes they wanted to build as and when they felt it right: Not having to build the routes in an order requested by the front-end team resulted in a far quicker time to staging for real testing and higher quality code base.

Change request, as with any project, happen as the client realises new potential. As and when change requests arrive that affect the back-end, the first step was to evolve the API design, ie the DDD file. After publishing the changes to the new API design(s) both the front-end and back-end could pull the updated changes and keep on building.

In addition to this, one of the API’s we built would also be consumed by a 3rd party application and once again, as the API was clearly defined by the DDD principles the said 3rd party could happily mock the API’s responses to build their part without much if any interaction with the API build team.

Looking to the future

DDD has given us some very big gains as described, but what could the future look like and how do we aim to streamline this process yet further.

Currently the API design must be written in a single Yaml file. When the API gets bigger than trivial the need to break the file down into sizeable chunks becomes a must, this is where swagger-chunk comes in. swagger-chunk allows the developer to write many smaller and manageable Yaml files which swagger-chunk then combines together into one.

Swagger-chunk is one step in the right direction, but it can be easy to get lost in a myriad of similar looking files. Further more, designing an API does not necessarily depend on skill of a developer if there were an alternative to writing pure Yaml chunks…. Enter the open source project of openapi-gui.

Openapi-gui is a graphical user interface to building the API design. The API designer does not require anything more than a web browser and technical knowledge on what a RESTfull API should be and deliver. In laymans terms, the API design can now be realised by a skilled technical product owner.

At acrontum we have yet to trial this technique and tool in production, but this does not mean we are not designing new processes to trail this, stay tuned for a future analysis...



11 May 2018

Technology English

by John