← Back to writing
Ā·1 min readĀ·#engenharia#soft skills

The Invisible Monster šŸ‘¹

Deadlines that never close, deliveries that slip, endless problems. Almost always the fault isn't technical — it's everything we let slide. A conversation about the invisible monster that sabotages teams.

Have you ever been in a situation on your team where nothing was working out? No deadline was ever met, deliveries kept slipping, the problems were endless, and there was no clear vision of where to go or what to do. This is quite common, and the solution may be simpler than it seems.

šŸ” What does ā€œimprovingā€ even mean?

There’s a phrase a lot of people repeat: ā€œWe have to improve 1% every day.ā€ But, in practice, what does improving mean? When we fail on a delivery, leave a problem unsolved, or the customer complains about something terrible that happened in the operation, that is just the result of a series of facts that piled up, often silently, and went unnoticed. Or, worse, were noticed and neglected.

There’s a lot in our day-to-day that we don’t give importance to. Want some examples? How many times have you gone into meetings to discuss a problem, everyone talked for hours, and by the end there was no formal document on how it would be solved, what the deadline was, the impact, or the way to mitigate it? How many times have you repeated a manual process without ever stopping to study how to automate it? How many times have you seen a problem — especially from other areas — and just complained that it existed, without proposing ideas (or even researching) how to improve it, because ā€œit was already here when I arrivedā€?

🧩 The problem is almost never technical

It seems too simple, but this is what really changes the game. When we have a technical problem, we always want to solve it from the technical side: let’s implement technology XYZ, switch to framework ABC, migrate from architecture A to B. When, in reality, the problem is usually cultural. To be transparent: I use the word ā€œcultural,ā€ but I might not agree 100% with the term. It’s just the closest thing to what I want to express.

šŸ½ļø The restaurant analogy

Stepping out of the technical and into the practical: if the restaurant served a bad meal, the fault isn’t the cook’s, and much less the ingredient used. The fault lies with the waiter who didn’t notice the problem and still served it late; with the cook who saw no problem in making it that way; with whoever stocked the food carelessly; with the buyer who maybe didn’t choose the best quality; with the manager who didn’t supervise the purchasing, the kitchen, and the waiter; with the owner who didn’t instruct the manager to implement clear processes. And so on. Until it becomes clear that the final product is the result of problems across every area, nothing will work out.

🌐 Bringing it to our world

Now, bringing it to our world: until the dev understands that a problem in finance is the company’s problem, that an infra problem is also an engineering problem, that observability is also their problem, that cloud cost is also their problem — nothing changes. This kind of behavior makes us think about the whole, and not just about what we’re doing. And that changes the game, because if everyone thinks this way, the chance of reducing errors is enormous.

ā€œBut, Bruno, are you telling me I should go over to finance and worry about the expense spreadsheet, even when everything is fine?ā€ Yes and no. If you see someone with a problem you can help solve, without harming the progress of your own tasks, help. Sometimes a simple automation (simple for us) saves the company a few thousand, freeing up cash to invest in areas like engineering itself.

I once heard a phrase that said: ā€œThis company looks like a boat, but with everyone rowing in a different direction.ā€ That’s exactly it. Imagine each person building their own Lego piece without coordinating with the others: what happens when it’s time to fit them together? A huge mess.

šŸ› ļø Don’t be just an engineer. Be a problem solver.

The main point is: don’t be just an engineer, be a problem solver. You’ll always learn something new (and knowledge is never too much), and things just might start falling into place.

The invisible monster lives in every step we neglect, don’t observe, don’t improve, and don’t bother to change. And this is where that ā€œ1% every dayā€ finally makes sense: improving isn’t adopting the trendy technology or swapping frameworks. It’s seeing what was invisible, taking on problems as your own — even the ones that weren’t born in your area — and acting on them. One noticed step, one documented process, one more automation. Every day. That’s how you defeat, little by little, the monster that no one sees.

Bruno Cunha

Bruno Cunha

Software engineer. I write about performance, .NET and the inner workings of systems that scale.