No Delay: Leaders Delay Cost a lot

Let me remove the obvious issues before I make my point. Ignoring problems is bad; ignoring problems at scale is even worse. If we have a network effect of ignoring things at scale, that's the worst thing we can do. Ignoring problems leads to Ignoring culture. Being aggressive with problems is not being reckless; it's not about moving so fast that we break things by doing it so. When applying for software, we ask some apparent questions but sometimes forget to apply for people. In software, we don't want to discover all the bugs in production; we want to shift left and find as many problems as possible before going to production. We must apply the shift left to people and address the issues immediately. The sooner we find problems, the sooner we fix them, and the sooner things improve. 

The Problem with Delayed Feedback

We could be doing something wrong for a whole quarter when we have a feedback cycle that is 1x per quarter. We need to do better than that. Weekly feedback forces us to make mistakes and, in the worst-case scenario, do wrong things for at most a week.

If we only give feedback in 1:1 sessions, then 1:1 sessions happen 1x per month. We only have 1 shot to fix in the month, and this is only 12 opportunities per year. This is too slow. Like in CI/CD, where we want continuous deployments, we want feedback to reach people as soon as possible and as frequently as possible.

The second problem with delay feedback is that, very likely people don't get. They think they get it, but they do not get it. They will understand the words you are saying, but they will not know how to do exactly better or even differently. That's why people need to do unit tests. People need to ask questions to validate that they understand all the time.

Better Defaults

Leaders just assume people did not get it, and they did not ask enough questions, which is often a much better default than assuming that everybody got it. For people, it's much better to assume that you do not understand, assume you don't get it, and always ask a couple of questions to validate understanding.

Again, people understand the words and might think they get the meaning, but they don't know what you know, and they don't know how to make it better like you do. That's why when we disagree, we need to give examples and explain why that matters and how we can improve it.

Example:

A engineer does a PR with a object full of constants.

One could say: Use a proper object-oriented design and kill this file.

The problems here are the following:

• We imply people know what is proper object-oriented design.
• Deleting files is obvious, but what should be put there instead?
• Clearly, and very often, people don't see why something is wrong (that's why they need to ask for more feedback).

In order to do better, we need questions the engineer could ask:

• What is wrong with my code?
• Why are constants a bad idea?
• How can I make it better?

The person giving he feedback can say:

Constants force the logic upon the client; if you have 10 clients, you will have that logic in ten places, and clearly, we are not making good abstractions. Object-oriented design is about hiding information; it's about providing benefits. You can't provide benefits just with data; you need data and functions. So a class that only has getters/setters does not help. However, a class with data and methods can help you if you do it right. 

What can we also take as lessons learned here?

• Some feedbacks are better with examples and POCs like this https://github.com/diegopacheco/java-pocs/tree/master/pocs/if-killer-proper-oop (some problems that constants have - enums have it as well - it's the same).
• Even during a conference call where explanations can be better elaborated.
• People can show they do not understand by side effects like: Not asking questions, taking a long time to finish, back and forth, etc..

What it's not fixed: Keeps happening

If we don't fix problems, they keep happening. All problems must be fixed as soon as possible, call outs need to be made, explanations and support must happen. Otherwise a culture of low-bar and intention to results is created where whatever you do is fine. 

Often, people don't want to bother others with "negative feedback," but that's the wrong way to see it. One thing to improve is feedback; otherwise, we won't get better. Ignoring the problems only makes them bigger and worse. 

Repetition is not a bad thing. Because teams are not static, as you get new people, you need to teach the same things again. Writing things down, having a history, using Wikipedia, and having chat history all help. But nothing helps more than people helping each other. It creates boundaries, strengthens relationships, and is one of the best team-building exercises. One person's problem is a team problem.

Senior engineers must help junior engineers. No matter how much noise it could create, you need to think about the network effect and what kind of culture is being made if silence prevails. Not all engineers have the same expertise; if we don't help each other, who will?

Delivery matters, and matters a lot, however deliver without learning is a big mistake. Delaying feedback is delay learnings. In order to scale, we must scale learning. Effective learning is how scale happens correctly. Never delay feedback, never delay questions, and always prioritize learning.

cheers,

Diego Pacheco