You have 0 further articles remaining this month. Join for free to read unlimited articles.


Feedback is a complicated subject that we as a community spend a lot of time thinking about. Much of this thought is focused on the how of feedback, both giving feedback and receiving. While these are both essential topics to discuss, one thing that gets left out of the discussion is how often we give it.

2023 Conferences & Events Events
graphic element

2023 Calendar - Join us in San Francisco and Berlin this year

Get unparalleled access to industry leaders. Learn from diverse voices in tech. Develop your skills as an engineering leader.

In her landmark book Accelerate, Nicole Forgsen describes the DORA4 metrics, which represent four different metrics that calculate the performance of a software development team. The ultimate goal of these four metrics is to make changes small, manageable, and frequent so that when things go well, you build more momentum, and when things go wrong, you can correct the mistakes quicker.

I believe this fundamental philosophy can also be applied to feedback, where giving it early and often is the best way to achieve a sustainable, healthy, and evolutionary feedback culture. 

You might have 1:1s, quarterly, and yearly reviews where you regularly give feedback to your reports, but I would argue this is not often enough. In a healthy feedback culture, people should be giving and receiving feedback almost every day. Applying these simple metrics will avoid the need for the big-bang feedbacks everyone dreads giving. Instead, you will foster a culture of constant corrections and adaptations that good feedback provides.

In this talk, I will propose a model much like the DORA4 model, except instead of focusing on metrics like time to merge and rate of recovery, I will focus on my personally developed metrics for feedback that ensure I am giving it early and often.

Good technical debt
Good technical debt
The (updated) story of why we migrate to gRPC and how we go about it
The (updated) story of why we migrate to gRPC and how we go about it