Working is like reinforcement learning in machine learning: when the reward function is not well defined, the agent will learn to exploit the environment to maximize the reward instead of solving the real problem. Eventually, people start pretending to work.

Information Flow

Is the feature even needed? Is the approach correct? It’s unlikely that we will get a clear technical specification directly from the product team. Usually, the process should start with a pain point or a growth opportunity. Once engineers understand the scope and context, they will provide solutions that fit the requirements. Better engineers—those with strong technical skills and rich domain knowledge—can even predict what will happen, so they leave room for flexibility and extensibility to accommodate future changes. If engineers get tickets like “Implement X (a feature) using Y (a vague technical approach) because Z (a team or the leadership) wants it,” which are confirmed but not actionable, then I believe some communication is missing: we should bring the person who is going to implement the feature back to the table.

Driven Only by KPIs

KPIs are a straightforward way to evaluate employees, much like exams for students. If a teacher places too much emphasis on grades, then learning is no longer the most effective way to get good grades. For example, tech debt is never considered in the KPIs, so dead code and outdated documentation are left in place. They mislead future engineers and AI agents, who then produce more garbage on top of the existing garbage. As no one has the full context and no one wants to take the risk of tackling the tech debt, the system becomes fragile, and developers need to put more effort into maintenance. Finally, the whole team realizes there is a problem because maintenance costs are too high and the team is exhausted from dealing with it. They decide to build a new system to replace the old one, even without compatibility, because they don’t know how the original one works. Such a big move definitely needs support from leadership, so the team starts making up stories and making empty promises to ensure they won’t get blamed. Yes, they are acting as if they are working.

Random Decisions

It’s a common phenomenon: when no one knows the full context (what problem to solve, how to solve it, what decisions we made before and why) and the team is under pressure to deliver, they always lean toward solving the problem with quick fixes, leaving potential issues for later. As all decisions are made so quickly, there are no proper records to refer back to. There is no mechanism to prevent this pattern from happening again. Everyone is busy with their own work without thinking long term, so the team is stuck in a vicious cycle.

Sometimes, because a decision is too big for one person to make, the team will have a meeting to discuss it and vote on it. Are all these options valid or feasible? Is the decision reversible? We pick the one that requires the least work, as always, no matter how reluctant you are (disagree but commit). Then a new feature comes up, and we realize the previous decision is not good enough, so we need to make a new one, and the cycle continues.

End

I am probably the one who says no the most, which reminds me of a saying from the late technical specialist Hao Chen, whom I greatly admired:

Do the right thing and wait to be fired.